Created attachment 1456935 [details] rhv-upload-video.log Description of problem: RHEL and win7/win2008r2 guests can't be installed qxl driver after v2v converting to rhv4.2 using --rhv-upload Version-Release number of selected component (if applicable): virt-v2v-1.38.2-6.el7.x86_64 libguestfs-1.38.2-6.el7.x86_64 rhv:4.2.4.4-0.1.el7_3 How reproducible: 100% Steps to Reproduce: 1.Install related nbdkit and python-ovirt-engine-sdk4 packages on v2v conversion server # rpm -qa |grep nbdkit nbdkit-1.2.4-3.el7.x86_64 nbdkit-plugin-python-common-1.2.4-3.el7.x86_64 nbdkit-plugin-python2-1.2.4-3.el7.x86_64 # rpm -qa |grep python-ovirt python-ovirt-engine-sdk4-4.2.7-1.el7ev.x86_64 2 Convert guest from vmware to rhv4.2 using --rhv-upload # virt-v2v -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.5-x86_64 -o rhv-upload -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -os nfs_data -op /tmp/rhvpasswd -oo rhv-cafile=/home/ca.pem -oo rhv-direct=true -of raw --password-file /tmp/passwd [ 0.1] Opening the source -i libvirt -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.5-x86_64 [ 1.9] Creating an overlay to protect the source from being modified [ 2.5] Initializing the target -o rhv-upload -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /tmp/rhvpasswd -os nfs_data [ 3.7] Opening the overlay [ 30.8] Inspecting the overlay [ 169.2] Checking for sufficient free disk space in the guest [ 169.2] Estimating space required on target for each disk [ 169.2] Converting Red Hat Enterprise Linux Server 7.5 (Maipo) to run on KVM virt-v2v: This guest has virtio drivers installed. [1269.7] Mapping filesystem data to avoid copying unused and blank areas [1271.8] Closing the overlay [1272.0] Checking if the guest needs BIOS or UEFI to boot [1272.0] Assigning disks to buses [1272.0] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/var/tmp/rhvupload.LEkuw0/nbdkit1.sock", "file.export": "/" } (raw) (100.00/100%) [2150.4] Creating output metadata [2168.0] Finishing off 3 Power on guest on rhv4.2 and check points for guest 3.1 Guest can get ip and restart network service normally if fix the bug1318922 manually 3.2 Virtio modules are listed in guest # lsmod |grep virtio virtio_rng 13029 0 virtio_balloon 18015 0 virtio_console 28075 2 virtio_net 28063 0 virtio_blk 18166 3 virtio_pci 22934 0 virtio_ring 22746 6 virtio_blk,virtio_net,virtio_pci,virtio_rng,virtio_balloon,virtio_console virtio 14959 6 virtio_blk,virtio_net,virtio_pci,virtio_rng,virtio_balloon,virtio_console 3.3 But guest doesn't have qxl driver although the graphic mode of guest is spice + qxl on rhv4.2, # lspci |grep VGA 00:02.0 VGA compatible controller: Cirrus Logic GD 5446 4.Check guest xml on registered host of rhv4.2, found the video mode is cirrus in guest libvirt xml, details pls refer to "rhv-upload-video-registered-host" # virsh dumpxml esx6.7-rhel7.5-x86_64 .... <video> <model type='cirrus' vram='16384' heads='1' primary='yes'/> <alias name='video0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </video> ... Actual results: As above description Expected results: RHEL and win7/win2008r2 guests can be installed qxl driver after v2v converting to rhv4.2 using --rhv-upload normally Additional info:
Created attachment 1456937 [details] guest-libvirt-xml
virt-v2v is adding a QXL device, like we always do for all RHV output modes: <Item> <rasd:Caption>Graphical Controller</rasd:Caption> <rasd:InstanceId>4ee0e12c-307f-42ce-8549-9032042c50e2</rasd:InstanceId> <rasd:ResourceType>20</rasd:ResourceType> <Type>video</Type> <rasd:VirtualQuantity>1</rasd:VirtualQuantity> <rasd:Device>qxl</rasd:Device> </Item> https://github.com/libguestfs/libguestfs/blob/4ed1bc5a79a77ad3a620b339f9ac2ecc8df6fd03/v2v/create_ovf.ml#L642-L654 Must be an oVirt problem.
do you have the OVF and/or engine.log?
(In reply to Richard W.M. Jones from comment #3) > virt-v2v is adding a QXL device, like we always do for all > RHV output modes: > > <Item> > <rasd:Caption>Graphical Controller</rasd:Caption> > > <rasd:InstanceId>4ee0e12c-307f-42ce-8549-9032042c50e2</rasd:InstanceId> > <rasd:ResourceType>20</rasd:ResourceType> > <Type>video</Type> > <rasd:VirtualQuantity>1</rasd:VirtualQuantity> > <rasd:Device>qxl</rasd:Device> > </Item> > > https://github.com/libguestfs/libguestfs/blob/ > 4ed1bc5a79a77ad3a620b339f9ac2ecc8df6fd03/v2v/create_ovf.ml#L642-L654 > > Must be an oVirt problem. The reason for this issue is [1]. When specifying an OVF that is supposed to be better compliant with the OVF specification, the hardware resource type of the video device must not be set to 20 because that conflicts with another device (IIRC, SATA controller) according to the OVF specification. Therefore, the hardware resource type of the video device should change to 32768 [2]. [1] https://gerrit.ovirt.org/#/c/87550/ [2] https://gerrit.ovirt.org/#/c/87550/4/backend/manager/modules/utils/src/main/java/org/ovirt/engine/core/utils/ovf/OvfHardware.java
See comments 2 and 3 in bz 1534644.
If we change: - <rasd:ResourceType>20</rasd:ResourceType> + <rasd:ResourceType>32768</rasd:ResourceType> that should work? I guess the bigger lesson is you can't just change the OVF that oVirt accepts without checking if virt-v2v could generate those fragments.
https://www.redhat.com/archives/libguestfs/2018-July/msg00027.html
Upstream in commit 296b2f66c71df0bf5ee2ee605fe4b92672796ab3
Moving back to ASSIGNED. The fix is wrong because (incredibly) the constant required is different depending on whether we're in RHVExportStorageDomain flavour or not. So we need to send the old constant for RHVExportStorageDomain, and the new constant only for OVirt flavour.
Fixed upstream with: https://github.com/libguestfs/libguestfs/commit/aa9e18f6d1fd503822dfd2124b92a2c67704c4c1 which is in libguestfs >= 1.39.7.
Verify the bug with builds: virt-v2v-1.38.2-8.el7.x86_64 libguestfs-1.38.2-8.el7.x86_64 libvirt-4.5.0-3.el7.x86_64 qemu-kvm-rhev-2.12.0-7.el7.x86_64 virtio-win-1.9.4-2.el7.noarch libguestfs-winsupport-7.2-2.el7.x86_64 ovirt-imageio-daemon-1.4.1-0.el7ev.noarch rhv:4.2.5-0.1.el7ev Steps: 1.Convert a rhel guest from vmware to rhv4.2 using rhv-upload # virt-v2v -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1 esx6.7-rhel7.5-x86_64 -o rhv-upload -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -os nfs_data -op /tmp/rhvpasswd -oo rhv-cafile=/home/ca.pem -oo rhv-direct=true -of raw --password-file /tmp/passwd -v -x |& tee > graphic-8.log 2.Power on guest on rhv4.2 and check guest,VGA device has qxl driver # lspci |grep VGA 00:02.0 VGA compatible controller: Red Hat, Inc. QXL paravirtual graphic card (rev 04) 3.Check virt-v2v conversion log, ResourceType of QXL devices has been changed from 20 to 32768 # cat graphic-8.log .... <Item> <rasd:Caption>Graphical Controller</rasd:Caption> <rasd:InstanceId>77d90492-b0a2-4843-9e12-1a5135b99949</rasd:InstanceId> <rasd:ResourceType>32768</rasd:ResourceType> <Type>video</Type> <rasd:VirtualQuantity>1</rasd:VirtualQuantity> <rasd:Device>qxl</rasd:Device> </Item> .... 4.Convert win7/win2008r2 guest from VMware to RHV4.2 using rhv-upload # virt-v2v -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1 esx6.7-win7-i386 -o rhv-upload -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -os nfs_data -op /tmp/rhvpasswd -oo rhv-cafile=/home/ca.pem -oo rhv-direct=true -of raw --password-file /tmp/passwd -on win7-v2v-8 [ 0.3] Opening the source -i libvirt -ic vpx://vsphere.local%5cAdministrator.73.141/data/10.73.75.219/?no_verify=1 esx6.7-win7-i386 [ 2.6] Creating an overlay to protect the source from being modified [ 3.6] Initializing the target -o rhv-upload -oc https://ibm-x3250m5-03.rhts.eng.pek2.redhat.com/ovirt-engine/api -op /tmp/rhvpasswd -os nfs_data [ 5.5] Opening the overlay [ 20.1] Inspecting the overlay [ 92.1] Checking for sufficient free disk space in the guest [ 92.1] Estimating space required on target for each disk [ 92.1] Converting Windows 7 Ultimate to run on KVM virt-v2v: warning: /usr/share/virt-tools/pnp_wait.exe is missing. Firstboot scripts may conflict with PnP. virt-v2v: This guest has virtio drivers installed. [ 120.2] Mapping filesystem data to avoid copying unused and blank areas [ 121.4] Closing the overlay [ 121.9] Checking if the guest needs BIOS or UEFI to boot [ 121.9] Assigning disks to buses [ 121.9] Copying disk 1/1 to qemu URI json:{ "file.driver": "nbd", "file.path": "/var/tmp/rhvupload.vLKNG1/nbdkit1.sock", "file.export": "/" } (raw) (100.00/100%) [1148.5] Creating output metadata [1163.7] Finishing off 5.Power on guest on rhv4.2 and checkpoints of guest are passed (display device has been installed qxl driver) Result: RHEL and win7/win2008r2 guests could be installed qxl driver after v2v rhv-upload conversion, so move 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/RHEA-2018:3021