导读：
本文系原创，欢迎规范转载。
本文描述了如何处理linux虚拟机从xen虚拟化迁移kvm虚拟化遇到问题，包括重建initramfs，处理未卸载的tools等。
系列文章：
xen2kvm迁移-Windows篇
xen2kvm迁移-Linux篇
迁移环境：
源平台：华为FusionComputeV100R006C10SPC101
目标平台：基于KVM虚拟化的云平台，本文以原生的libvirt为例
虚拟机：centos 7.6
具体操作步骤：
1、在源平台导出格式为ovf的磁盘镜像
导出后，得到vhd文件：centos_xen-1.vhd。将该文件传输到一个装有libvirt和相关工具套件的Linux环境上，本文所使用的是一台centos7.6物理机，部署了GUI界面，安装了libvirt libvirt-client qemu-img virt-manager等工具。
2、下载华为自研的qemu-img-hw命令
解压得到命令，为命令赋予执行权限：
[root@hyperhost ~ ]$ unzip qemu-img-hw.zip
[root@hyperhost ~ ]$ cd qemu-img-hw.zip
[root@hyperhost ~ ]$ chmod a+x qemu-img-hw
使用该命令查看导出vhd文件格式：
据华为公有云文档描述：zvhd和zvhd2是云服务内部自研格式，qemu-img工具无法识别这两种格式的镜像文件，需要使用华为自研的qemu-img-hw工具：
[root@hyperhost ~ ]$ ./qemu-img-hw info centos_xen-1.vhd
image: centos_xen-1.vhd
file format: zvhd
virtual size: 100G (107374182400 bytes)
disk size: 769M
如果使用原生的qemu-img命令查看镜像格式，会显示raw，会误导用户接下来错误的执行转换命令:
[root@hyperhost ~]$ qemu-img info centos_xen-1.vhd
image: centos_xen-1.vhd
file format: raw
virtual size: 769M (806404096 bytes)
disk size: 769M
3、将zvhd格式转换为qcow2格式
转换时间依数据量而定
[root@hyperhost ~]$ ./qemu-img-hw convert -p -f zvhd -O qcow2 centos_xen-1.vhd centos_xen.qcow2
(100.00/100%)
# 转换成功：
[root@hyperhost ~]$ qemu-img info centos_xen.qcow2
image: centos_xen.qcow2
file format: qcow2
virtual size: 100G (107374182400 bytes)
disk size: 1.6G
cluster_size: 65536
Format specific information:
compat: 1.1
lazy refcounts: false
refcount bits: 16
corrupt: false
4、部署为kvm虚拟机
本文使用virt-manager将qcow2磁盘部署为虚拟机：
5、启动虚拟机，处理故障
本虚拟机安装时使用了lvm逻辑卷，会报此卡在启动界面：
超时后提示用户，找不到逻辑卷：
重启：
按鼠标下键，进入rescue kernel：
重建initramfs文件，扫描vg，激活vg，重启虚拟机
先尝试重建initramfs文件，如果不行再尝试扫描、激活vg。
# 重建initramfs文件
[root@localhost ~]# dracut -f
# 扫描vg
[root@localhost ~]# lvm vgscan
# 激活vg
[root@localhost ~]# lvm vgchange -ay
# 重启
[root@localhost ~]# init 6
以默认内核启动
启动正常：
6、另一个场景
现在看另一个场景，需要迁移的虚拟机为centos7：
- 安装了GUI，并且日常以图形化界面启动；
- 安装了华为的uvp-tools；
- 没有使用lvm；
- 启用了selinux；
排查思路：
转换qcow2格式的镜像、上传kvm环境这些操作都一样：
[root@hyperhost ~]$ qemu-img-hw convert -p -f zvhd -O qcow2 centos_1qaz-1.vhd centos_1qaz-1.qcow2
在之前的场景下，正常启动时报错无法找到磁盘，针对这种情况，需要使用dracut -f 重建initramfs。
并且因为找到不到磁盘，所以无法挂载根磁盘chroot进行修复，因此需要在rescue kernel启动。
但是在安装了GUI的场景下，使用rescue kernel会卡在数字logo启动界面：
这里因为有GUI，所以我们无法知道到卡住的原因，所以我们尝试挂载iso镜像，进入救援模式进行修复。
进入救援模式后，按照说明输入1选择继续，这里提示我们需要救援的环境已经被挂载到了/mnt/sysimage，此时按下回车继续，执行chroot /mnt/sysimage进入我们要救援的系统：
执行dracut -f重建initramfs，这里我们顺便禁用selinux：
如果有多个kernel，这里需要执行：dracut --regenerate-all -f
两次输入exit，退出救援模式。这次我们选择使用本地盘启动。并且之前因为GUI的原因，我们无法看到启动时的boot message，这里我们解决这个问题：
选择第一个内核，按下e进入编辑：
将linux16开头的这行中rhgb quiet内容删掉，按下ctrl+x组合键：
其中：
rhgb = redhat graphical boot
quiet = 静默模式，不显示boot message
启动后，会卡在这里，我们发现，这里提示Xen_hcall：DomU hypercall user-space has been created.
Xen_hcall是xen的半虚拟化驱动，该驱动要和主机的xen api(其实就是hypercall)通信，因为我们已经迁移到kvm环境上，该驱动本应该在导出之前卸载，这里我们演示如何处理没有卸载tools的情况：
强制重启，重新进入光盘救援模式，在/etc/.uvp-monitor路径下果然发现tools没有卸载，尝试执行卸载脚本无法执行：
这里我们的思路是，xen_hcall是一个模块，在开机时自动加载，因此我们去开机启动脚本看看，果然发现加载xen_hcall的命令:
尝试修该文件，发现没有权限，为其添加权限，chmod u+w /etc/rc.d/rc.local，然后修改文件：
重新启动，注意从本地盘启动，发现已经可以正常启动了:
在实际操作过程中，处理完xen_hcall模块的问题后，笔者两次发现了虚拟机启动会卡在nfs这里：
经过排查发现，安装图形化桌面时，会自动安装nfs并启用，如果出现这种情况，需要再次进入救援模式，删除nfs-client.taget的软链接，避免开机自动启动。
rm /etc/systemd/system/nfs-client.target
后续工作：
- 卸载cdrom设备，或者修改启动顺序，从本地盘启动；
- 卸载uvp vm-tools；
思路总结：
- 如果出现无法找到根磁盘，则必须重建initramfs，如果有多个内核，要对所有内核进行重建：
dracut --regenerate-all -f - 如果虚拟机安装了tools，导出前需要卸载；如果没卸载可以参考本文处理；
- 如果虚拟机使用了图形化，为了便于在启动时看到报错信息，需要编辑grub菜单去掉rhgb quiet参数；
