I have done some P2V migration recently. Now I will summarize some of the problems encountered in the process and the solutions for the reference of students in need.
Most of the problems encountered so far are due to the fact that when the original physical machine installed the system, the startup method was UEFI. For some physical nodes that use the Legacy method to start, they have not encountered anything particularly difficult to solve after P2V.
In the scenario introduced in this article, after P2V conversion is completed, the KVM virtual machine is running on the centos7.7 host.
P2V in windows environment
- Problem description 1:
After converting the Windows physical node into a virtual machine through P2V, it can be started normally in the VMware environment, but it starts abnormally in kvm mode.
Solution 1: Most of the problems encountered are because the Windows system uses a GPT format boot partition, and it is necessary to use winPE to perform boot repair and convert GPT to MBR for booting.
First download an image file with winPE, such as Ton8PE_5.0_376.iso,
then create a virtual machine, set the first startup item of the virtual machine to this iso image, and set other files of the Windows system KVM virtual machine to other Hard disk
: Start the virtual machine to perform repair work (you can find the information by yourself, there is currently a lot of corresponding information on the Internet)
P2V in Linux environment
For Linux virtual machines, there is no way to modify the boot partition. Therefore, it can only be operated on the host machine. Yes, the host machine supports UEFI boot.
For systems where the host is CentOS7.7:
1) Install the edk2.git-ovmf-x64-0-20190308.984.g6c27a4d337.noarch.rpm software package
2) Configure it in the /etc/libvirt/qemu.conf file (note The path remains consistent with the actual location)
nvram = [
"/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd:/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi .fd”
]
3) Restart the libvirtd service systemctl restart libvirtd
4) For virtual machines in Linux systems, you need to use UEFI to boot. The configuration file needs to add the following content
<os>
<type arch='x86_64'>hvm</type>
<loader readonly='yes' type='pflash'>/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd</loader>
<nvram template='/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd'/>
</os>
5) Edit virtual machine startup items
- Problem description 2
: How to distinguish whether Linux is started in UEFI mode or Legacy mode.
Solution 2: Use the lsbk command. If the system disk has two partitions, /boot and /boot/efi, both are booted in UEFI mode. If there is only one /boot partition, it is started in Legacy mode.
- Problem description 3
: Error when starting virtual machine
error: cant't find command 'linux16'.
error: cant't find command 'initrd16'.
Solution 3: Press e when the virtual machine starts to enter the startup item editing mode, change "linux16 /vmlinuz..." and "initrd16 /vmlinuz..." to "linuxefi /vmlinuz..." and "initrdefi /vmlinuz..." to enter the system. Then change linux16 in the file /etc/grub2-efi.cfg (this is a link file) to linuxefi, change initrdefi to initrdefi, then save and exit. Restart the virtual machine and see if you can enter the system normally.
- Problem description 4:
When using virsh define to declare a virtual machine, it prompts "smm is not available with this QEMU binary".
Solution 4: This reason is caused by the qemu-img version being too low. The qemu version is preferably above 2.8 (qemu-img --version). It should be noted here that the name of the higher version of qemu-img is qemu-img-ev, so you need to install the qemu-img-ev qemu-kvm-common-ev qemu-kvm-ev qemu-kvm-tools-ev software package to upgrade the version.
- Problem description 5:
The virtual machine cannot be started into the system. How to modify the startup items or files.
Solution 5: First create a virtual machine that can be started normally, and then mount the virtual machine file that failed to start to the virtual machine file that can be started normally. Modify the mount according to the partition structure of the original physical machine node. The operation here is a bit complicated. Partitioning in lvm mode also involves the repair of VG LV. Here I only provide a method that I used to solve the problem. If you encounter problems during the specific operation, you need to analyze them in detail.
- Problem description 6:
The virtual machine (Red Hat Enterprise Linux Server release 6.5) cannot be started into the system and the boot disk cannot be found.
Solution 6: This problem is encountered on the virtual machine of Red Hat Enterprise Linux Server release 6.5. Finally, I found out that the drive letter changed after P2V. The system disk in the physical machine is sda, but after P2V virtualization, the boot disk becomes vda. Here, after mounting the virtual machine file to a normal virtual machine, the contents of the /boot/grub/device.map file of the radhat virtual machine are
# this device map was generated by anaconda
(hd0) /dev/sda
change into
# this device map was generated by anaconda
(hd0) /dev/vda
Then the redhat 6.5 virtual machine can be started normally.
There are many minor problems encountered in the P2V process. Some of them can be solved by searching for information online, but they are briefly mentioned or not listed.
This article mainly summarizes the methods that I have found useful. P2V operations are complicated and the problems encountered are all kinds of strange. Specific problems need to be analyzed in detail.
Welcome everyone to communicate!