Created attachment 1346299 [details] virt-v2v-software-RAID.log Description of problem: Virt-v2v can't convert rhel7.4 guest whose OS is installed on software RAID with UEFI mode Version-Release number of selected component (if applicable): virt-v2v-1.36.10-1.el7.x86_64 libguestfs-1.36.10-1.el7.x86_64 libvirt-3.8.0-1.el7.x86_64 qemu-kvm-rhev-2.10.0-3.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1.Prepare a rhel7.4 guest whose OS is installed on software RAID1 with UEFI mode in virt-manager # virsh dumpxml rhel7.4-md .... <os> <type arch='x86_64' machine='pc-q35-rhel7.5.0'>hvm</type> <loader readonly='yes' secure='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.secboot.fd</loader> <nvram>/var/lib/libvirt/qemu/nvram/rhel7.4-md_VARS.fd</nvram> <boot dev='hd'/> </os> .... <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/rhel7.4-md.qcow2'/> <target dev='sda' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/rhel7.4-md-1.qcow2'/> <target dev='sdb' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/var/lib/libvirt/images/rhel7.4-md-2.qcow2'/> <target dev='sdc' bus='sata'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> .... 2.Convert the guest to rhv by virt-v2v, but v2v failed in converting the guest # virt-v2v rhel7.4-md -o rhv -os 10.73.131.93:/home/nfs_export -of raw [ 0.0] Opening the source -i libvirt rhel7.4-md [ 0.0] Creating an overlay to protect the source from being modified [ 0.7] Initializing the target -o rhv -os 10.73.131.93:/home/nfs_export [ 5.3] Opening the overlay [ 14.9] Inspecting the overlay [ 39.4] Checking for sufficient free disk space in the guest [ 39.4] Estimating space required on target for each disk [ 39.4] Converting Red Hat Enterprise Linux Server 7.4 (Maipo) to run on KVM virt-v2v: error: no bootloader detected If reporting bugs, run virt-v2v with debugging enabled and include the complete output: virt-v2v -v -x [...] Actual results: As above description Expected results: Virt-v2v can convert rhel7.4 guest whose OS is installed on software RAID1 with UEFI mode Additional info: Virt-v2v can convert rhel7.4 guest whose OS is installed on software RAID1 with legacy BIOS mode
I see what is the problem: the /boot partition is not detected, as the grub.cfg file is not directly within the grub2 subdirectory. Can you please paste the output of `tree -spa /boot` within the running guest?
(In reply to Pino Toscano from comment #2) > I see what is the problem: the /boot partition is not detected, as the > grub.cfg file is not directly within the grub2 subdirectory. Can you please > paste the output of `tree -spa /boot` within the running guest? # tree -spa /boot /boot ├── [-rw-r--r-- 140894] config-3.10.0-693.el7.x86_64 ├── [drwx------ 16384] efi │ └── [drwx------ 2048] EFI │ ├── [drwx------ 2048] BOOT │ │ ├── [-rwx------ 1301312] BOOTX64.EFI │ │ └── [-rwx------ 77592] fbx64.efi │ └── [drwx------ 2048] redhat │ ├── [-rwx------ 182] BOOT.CSV │ ├── [-rwx------ 182] BOOTX64.CSV │ ├── [drwx------ 2048] fonts │ │ └── [-rwx------ 2560080] unicode.pf2 │ ├── [-rwx------ 4589] grub.cfg │ ├── [-rwx------ 1024] grubenv │ ├── [-rwx------ 1050064] grubx64.efi │ ├── [-rwx------ 1261360] mmx64.efi │ ├── [-rwx------ 1301312] shim.efi │ ├── [-rwx------ 1301312] shimx64.efi │ └── [-rwx------ 1295152] shimx64-redhat.efi ├── [drwx------ 4096] grub2 │ └── [lrwxrwxrwx 28] grubenv -> /boot/efi/EFI/redhat/grubenv ├── [-rw------- 69463851] initramfs-0-rescue-baf8ce6ad7334dde9b4d1035968770ab.img ├── [-rw------- 28661698] initramfs-3.10.0-693.el7.x86_64.img ├── [-rw-r--r-- 10184637] initrd-plymouth.img ├── [-rw-r--r-- 293027] symvers-3.10.0-693.el7.x86_64.gz ├── [-rw------- 3228420] System.map-3.10.0-693.el7.x86_64 ├── [-rwxr-xr-x 5875184] vmlinuz-0-rescue-baf8ce6ad7334dde9b4d1035968770ab ├── [-rwxr-xr-x 5875184] vmlinuz-3.10.0-693.el7.x86_64 └── [-rw-r--r-- 166] .vmlinuz-3.10.0-693.el7.x86_64.hmac # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 9G 0 disk ├─sda1 8:1 0 8.8G 0 part │ └─md127 9:127 0 8.8G 0 raid1 / └─sda2 8:2 0 51M 0 part └─md125 9:125 0 51M 0 raid1 /boot/efi sdb 8:16 0 9G 0 disk ├─sdb1 8:17 0 8.8G 0 part │ └─md127 9:127 0 8.8G 0 raid1 / ├─sdb2 8:18 0 21M 0 part │ └─md126 9:126 0 21M 0 raid1 [SWAP] └─sdb3 8:19 0 51M 0 part └─md125 9:125 0 51M 0 raid1 /boot/efi sdc 8:32 0 9G 0 disk ├─sdc1 8:33 0 8.8G 0 part │ └─md127 9:127 0 8.8G 0 raid1 / ├─sdc2 8:34 0 21M 0 part │ └─md126 9:126 0 21M 0 raid1 [SWAP] └─sdc3 8:35 0 51M 0 part └─md125 9:125 0 51M 0 raid1 /boot/efi sr0 11:0 1 1024M 0 rom
Actually I need to change my statement: the detection is fine, but due to bug 1217444 v2v does not know the guest uses UEFI, and thus its bootloader detection does not look in /boot/efi/EFI. Other than fixing bug 1217444, a solution is to use the new bootloader detection code, done with the upstream commit a76e9040b20f97eb5c9accbefcbf55999554dc48, which should work also when the firmware is not known. This commit seems to work at a quick testing, so I'll backport it.
Try to verify the bug with below builds: virt-v2v-1.36.10-2.el7.x86_64 libguestfs-1.36.10-2.el7.x86_64 libvirt-3.9.0-1.el7.x86_64 qemu-kvm-rhev-2.10.0-4.el7.x86_64 OVMF-20171011-1.git92d07e48907f.el7.noarch Steps: 1.Prepare a rhel7.4 guest whose OS is installed on software RAID1 with UEFI mode in virt-manager. 2.Convert the guest to rhv by virt-v2v. # virt-v2v rhel7.4-raid1-uefi -o rhv -os 10.73.131.93:/home/nfs_export [ 0.0] Opening the source -i libvirt rhel7.4-raid1-uefi [ 0.1] Creating an overlay to protect the source from being modified [ 1.2] Initializing the target -o rhv -os 10.73.131.93:/home/nfs_export [ 1.7] Opening the overlay [ 5.6] Inspecting the overlay [ 17.1] Checking for sufficient free disk space in the guest [ 17.1] Estimating space required on target for each disk [ 17.1] Converting Red Hat Enterprise Linux Server 7.4 (Maipo) to run on KVM virt-v2v: This guest has virtio drivers installed. [ 49.3] Mapping filesystem data to avoid copying unused and blank areas virt-v2v: warning: fstrim on guest filesystem /dev/md124 failed. Usually you can ignore this message. To find out more read "Trimming" in virt-v2v(1). Original message: fstrim: fstrim: /sysroot/: the discard operation is not supported [ 50.6] Closing the overlay [ 50.8] Checking if the guest needs BIOS or UEFI to boot [ 50.8] Assigning disks to buses [ 50.8] Copying disk 1/2 to /tmp/v2v.0RL0QK/bdf9c90b-e6f0-439c-aa9f-6305fd5fad7e/images/020f0c6b-c5b1-4415-a82f-2b965db6cd09/262b3a70-9c1f-4350-a955-34385ac45caf (raw) (100.00/100%) [ 66.8] Copying disk 2/2 to /tmp/v2v.0RL0QK/bdf9c90b-e6f0-439c-aa9f-6305fd5fad7e/images/808dc773-7993-4dca-a772-6aef83fd0f57/cd656ff3-01f7-450a-8e6c-4b0d863e00bf (raw) (100.00/100%) [ 83.6] Creating output metadata [ 83.7] Finishing off 3.Login RHV4.1,and try to boot the guest but can't boot into system as attachment picture,and you could get v2v log from attachment also. Hi,pino,from the result it looks like the bug also has some problem.
Created attachment 1348431 [details] can't-boot-into=os
Created attachment 1348433 [details] v2v-can't-boot.log
Another scenario: Convert the comment6 guest to local(it is means convert libvirt guest to libvirt just for testing) also has the problem.
Sorry, my comment6 scenario is wrong but it contain another issue. You see i convert a uefi guest to rhv,but rhv target was not support,but i could do the conversion successfully.But the conversion should failed as expect. I conclude as below here. Try to verify the bug with below builds: virt-v2v-1.36.10-2.el7.x86_64 libguestfs-1.36.10-2.el7.x86_64 libvirt-3.9.0-1.el7.x86_64 qemu-kvm-rhev-2.10.0-4.el7.x86_64 OVMF-20171011-1.git92d07e48907f.el7.noarch Scenario1: 1.Convert the uefi-md guest to local just for testing. #virt-v2v rhel7.4-raid1-uefi -on new-raid1-uefi -v -x |& tee > v2v.log 2.After conversion,boot the guest and also can't boot OS,and you could get the new v2v log. Scenario 2: 1.Convert the uefi-md guest to rhv. # virt-v2v rhel7.4-raid1-uefi -o rhv -os 10.73.131.93:/home/nfs_export 2.From the comment6 ,we could see the conversion is successfully. So, from scenario 1, i think the bug has not fixed . And from scenario 2, is it a new bug? (others uefi guest work as expect)
Created attachment 1348492 [details] v2v-local-to-local
There are three problems in this case: a) the code inspecting the libvirt XML cannot detect the firmware type at the moment -- bug 1217444 is somehow related in this b) the fact that the guest uses RAID means the GUID of the RAID partitions in the disks is not the UEFI one, so v2v does not find any UEFI partition c) v2v does not support export to RHV with UEFI -- see bug 1112275 In particular, there is not much that can be done about (b), other than providing the information about the firmware when parsing the libvirt XML of the guest. Considering (c), you could check that this is fixed (i.e. when (a) is fixed) by using a different export method that support UEFI, like -o libvirt.
BTW I just opened bug 1509931 as RFE for export of UEFI guests to RHV, so this is tracked.
As your said the bug was blocked by bug 1217444.
Unfortunately not fully fixed.
(In reply to Pino Toscano from comment #12) > There are three problems in this case: > > a) the code inspecting the libvirt XML cannot detect the firmware type at > the moment -- bug 1217444 is somehow related in this This will be fixed in libvirt 5.3.0, and hopefully it should be enough to get this. Hence, move it the new major release, and mark it as TestOnly.
(In reply to Pino Toscano from comment #17) > Hence, move it the new major release, and mark it as TestOnly. Actually, there are (small) changes needed for this: fb7983f999004c1f8100776819ea65b21990956d
Verify bug with builds: virt-v2v-1.40.2-10.module+el8.1.0+3311+ebd017c2.x86_64 libguestfs-1.40.2-10.module+el8.1.0+3311+ebd017c2.x86_64 libvirt-5.4.0-1.module+el8.1.0+3304+7eb41d5f.x86_64 qemu-kvm-4.0.0-4.module+el8.1.0+3356+cda7f1ee.x86_64 Steps: 1.Prepare a rhel7.6 guest whose OS is installed on software RAID1 with UEFI mode in Vmware. # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 374K 0 rom /run/media/root/config-2 sr1 11:1 1 1024M 0 rom vda 252:0 0 8G 0 disk ├─vda1 252:1 0 6G 0 part │ └─rhel_bootp--73--75--199-root 253:0 0 8.1G 0 lvm / ├─vda2 252:2 0 1.2G 0 part │ └─md127 9:127 0 1.2G 0 raid1 /boot └─vda3 252:3 0 902M 0 part └─md126 9:126 0 902M 0 raid1 /boot/efi vdb 252:16 0 4G 0 disk ├─vdb1 252:17 0 1.2G 0 part │ └─md127 9:127 0 1.2G 0 raid1 /boot └─vdb2 252:18 0 902M 0 part └─md126 9:126 0 902M 0 raid1 /boot/efi vdc 252:32 0 5G 0 disk ├─vdc1 252:33 0 3G 0 part │ ├─rhel_bootp--73--75--199-root 253:0 0 8.1G 0 lvm / │ └─rhel_bootp--73--75--199-swap 253:1 0 800M 0 lvm [SWAP] ├─vdc2 252:34 0 1.2G 0 part │ └─md127 9:127 0 1.2G 0 raid1 /boot └─vdc3 252:35 0 902M 0 part └─md126 9:126 0 902M 0 raid1 /boot/efi 2.Use virt-v2v to convert the guest to RHV # virt-v2v -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.6-uefi-raid --password-file /tmp/passwd -o rhv-upload -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -os rhvh_data -op /tmp/rhvpasswd -oo rhv-cafile=/home/ca.pem -oo rhv-direct=true -oo rhv-cluster=rhvh [ 0.5] Opening the source -i libvirt -ic vpx://root.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.6-uefi-raid [ 4.8] Creating an overlay to protect the source from being modified [ 6.6] Opening the overlay [ 46.2] Inspecting the overlay [ 224.9] Checking for sufficient free disk space in the guest [ 224.9] Estimating space required on target for each disk [ 224.9] Converting Red Hat Enterprise Linux Server 7.6 (Maipo) to run on KVM virt-v2v: warning: guest tools directory ‘linux/el7’ is missing from the virtio-win directory or ISO. Guest tools are only provided in the RHV Guest Tools ISO, so this can happen if you are using the version of virtio-win which contains just the virtio drivers. In this case only virtio drivers can be installed in the guest, and installation of Guest Tools will be skipped. virt-v2v: This guest has virtio drivers installed. [1910.7] Mapping filesystem data to avoid copying unused and blank areas virt-v2v: warning: fstrim on guest filesystem /dev/md127 failed. Usually you can ignore this message. To find out more read "Trimming" in virt-v2v(1). Original message: fstrim: fstrim: /sysroot/: the discard operation is not supported [1915.7] Closing the overlay [1916.0] Assigning disks to buses [1916.0] Checking if the guest needs BIOS or UEFI to boot virt-v2v: This guest requires UEFI on the target to boot. [1916.0] Initializing the target -o rhv-upload -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /tmp/rhvpasswd -os rhvh_data [1919.4] Copying disk 1/3 to qemu URI json:{ "file.driver": "nbd", "file.path": "/var/tmp/rhvupload.vIbZ4f/nbdkit0.sock", "file.export": "/" } (raw) (100.00/100%) [2735.1] Copying disk 2/3 to qemu URI json:{ "file.driver": "nbd", "file.path": "/var/tmp/rhvupload.vIbZ4f/nbdkit1.sock", "file.export": "/" } (raw) (100.00/100%) [2978.1] Copying disk 3/3 to qemu URI json:{ "file.driver": "nbd", "file.path": "/var/tmp/rhvupload.vIbZ4f/nbdkit2.sock", "file.export": "/" } (raw) (100.00/100%) [3310.3] Creating output metadata [3332.2] Finishing off The conversion can be finished successfully. 3.Login to RHV and boot the guest,the guest can pass all regular checkpoints. Result: Virt-v2v can convert rhel guest whose OS is installed on software RAID with UEFI mode,So change the bug from ON_QA to VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:3723