Created attachment 1144563 [details] screenshot1 Description of problem: Windows guest has no virtio net driver after virt-v2v conversion on rhevh Version-Release number of selected component (if applicable): rhevm-3.6.5.1-0.1.el6 RHEV Hypervisor - 7.2 - 20160330.0.el7ev qemu-kvm-rhev-2.3.0-31.el7_2.7.x86_64 libvirt-1.2.17-13.el7_2.3.x86_64 vdsm-4.17.25-0.el7ev.noarch virt-v2v-1.28.1-1.55.el7.x86_64 libguestfs-1.28.1-1.55.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1. Login rhevm with webadmin -> virtual machines tab -> import 2. Enter VMware details -> select "proxy host" as rhevh host -> load the vms -> select a windows guest to import 3. At windows guest import dialog, click the option "Attach VirtIO-Drivers" to make sure virtio-win.iso is selected, and find the nic driver type is "e1000" at network interface of guest before conversion , pls refer to screenshot1. Click "ok" to start the conversion. 5. After conversion,found the windows guest has no virtio net driver in device manager as screenshot2 and net driver shows e1000 in guest info as screenshot3 Actual results: As above description Expected results: Windows guest could be installed virtio net driver after virt-v2v conversion on rhevh Addtional info:
Created attachment 1144564 [details] screenshot2
Created attachment 1144565 [details] screenshot3
*** This bug has been marked as a duplicate of bug 1323973 ***
Additional info: 1.SSH login rhevh host 2.Mount virtio-win.iso to rhevh host #mount rhevm_ip:/home/iso_domain /media 3.Set path for VIRTIO_WIN_DIR # export VIRTIO_WIN_DIR=/media/3024df98-1988-4051-aa84-78a821524e29/images/11111111-1111-1111-1111-111111111111/virtio-win-1.8.0.iso 4.Convert a windows guest on rhevh # virt-v2v -ic vpx://root.4.103/tzheng-demo/10.73.3.19/?no_verify=1 -b virbr0 esx5.5-win7-i386 -of raw --password-file /tmp/passwd -o rhev -os 10.73.2.1:/home/nfs_export -b ovirtmgmt -n ovirtmgmt [ 0.0] Opening the source -i libvirt -ic vpx://root.4.103/tzheng-demo/10.73.3.19/?no_verify=1 esx5.5-win7-i386 [ 1.0] Creating an overlay to protect the source from being modified [ 1.0] Opening the overlay [ 14.0] Initializing the target -o rhev -os 10.73.2.1:/home/nfs_export [ 14.0] Inspecting the overlay [ 52.0] Checking for sufficient free disk space in the guest [ 52.0] Estimating space required on target for each disk [ 52.0] Converting Windows 7 Ultimate to run on KVM virt-v2v: This guest has virtio drivers installed. [ 66.0] Mapping filesystem data to avoid copying unused and blank areas [ 67.0] Closing the overlay [ 68.0] Checking if the guest needs BIOS or UEFI to boot [ 68.0] Copying disk 1/1 to /tmp/v2v.HNV39e/7786f4e5-b04e-44e4-b909-363566201ffa/images/9f7d6f3d-a3d6-4835-9e7a-e9515c6810c9/05d01ce0-8402-47e3-8064-51c97bbd0cbd (raw) (100.00/100%) [ 626.0] Creating output metadata [ 626.0] Finishing off 5.After conversion, the windows guest has net virtio driver, so I think the bug is not related to rhevh
I think this bug has some difference with bug 1323973, thanks Hi Nsim, According your suggestion at IRC, I tried it as comment4, do you think the bug is similar with the issue option : vdsm is not passing the net virtio driver to v2v BR
(In reply to mxie from comment #4) you used "-b virbr0" parameter which is not used by vdsm. We don't support changing network interface(you can see it's not changeable in the Import VM UI) We chose to not expose too many of the parameters for the sake of UI simplicity, you can always change all of that after the conversion. Though I think it does make sense to change network to virtio by default.
I think there are two or three separate issues: (1) Does virt-v2v install virtio-net drivers in the guest? Can't tell. I would need to see the virt-v2v -v -x output from ovirt (NB: *NOT* from when you run the virt-v2v command by hand). Can ovirt collect the full virt-v2v -v -x output? (2) Does ovirt present a virtio-net device to the guest? Assuming virt-v2v managed to install a virtio-net device (see (1)) then virt-v2v should write an OVF file containing <Network> <rasd:ResourceSubType>3</rasd:ResourceSubType> </Network> where the "3" indicates virtio-net. And ovirt *should* use that information to present a virtio-net device to the guest. To tell if this happened, I would need to see the virt-v2v -v -x output from ovirt. (3) Do we need to use -b/-n options on the virt-v2v command line to remap networks?
oVirt 4.0 Alpha has been released, moving to oVirt 4.0 Beta target.
To me it seems like an oVirt bug, or rather "feature" because it seems to be done on purpose. To my understanding, if NIC is using either 'e1000' or 'rtl8139' driver then the driver is kept as is. In all other cases VirtIO is used. I tried to do the import in oVirt and to answer Richard's questions: (In reply to Richard W.M. Jones from comment #7) > I think there are two or three separate issues: > > (1) Does virt-v2v install virtio-net drivers in the guest? > > Can't tell. I would need to see the virt-v2v -v -x output > from ovirt (NB: *NOT* from when you run the virt-v2v command by > hand). I have found the drivers where they should be. That is in C:\Windows\Drivers\VirtIO. > Can ovirt collect the full virt-v2v -v -x output? No, this is currently not possible. > (2) Does ovirt present a virtio-net device to the guest? > > Assuming virt-v2v managed to install a virtio-net device > (see (1)) then virt-v2v should write an OVF file containing > <Network> > <rasd:ResourceSubType>3</rasd:ResourceSubType> > </Network> > where the "3" indicates virtio-net. And ovirt *should* > use that information to present a virtio-net device to > the guest. I looked into the generated OVF and there is: ... <rasd:ResourceType>10</rasd:ResourceType> <rasd:ResourceSubType>3</rasd:ResourceSubType> ... So this is OK too. > To tell if this happened, I would need to see the virt-v2v -v -x > output from ovirt. > > > (3) Do we need to use -b/-n options on the virt-v2v command > line to remap networks? I don't know if this could help or not.
(In reply to Tomáš Golembiovský from comment #12) > To me it seems like an oVirt bug, or rather "feature" because it seems to be > done on purpose. To my understanding, if NIC is using either 'e1000' or > 'rtl8139' driver then the driver is kept as is. In all other cases VirtIO is > used. The virt-v2v process does not touch the network driver in the Windows registry of the guest at all under any circumstances. HOWEVER if RHEV presents a virtio-net device to the guest after conversion, then the guest itself ought to install the right driver from C:\Windows\Drivers\VirtIO > > Can ovirt collect the full virt-v2v -v -x output? > > No, this is currently not possible. This and many other problems we have would be much easier to solve if this was fixed. > I looked into the generated OVF and there is: > > ... > <rasd:ResourceType>10</rasd:ResourceType> > <rasd:ResourceSubType>3</rasd:ResourceSubType> > ... > Can you attach the full OVF that virt-v2v generates. It's probably the best we can do for this bug.
Created attachment 1167864 [details] OVF file generated by virt-v2v
Thanks Tomáš. The following element in the XML: <Item> <rasd:InstanceId>3a02dd53-fdf5-4249-b67f-1342efcc9bdd</rasd:InstanceId> <rasd:Caption>Ethernet adapter on VM Network</rasd:Caption> <rasd:ResourceType>10</rasd:ResourceType> <rasd:ResourceSubType>3</rasd:ResourceSubType> <Type>interface</Type> <rasd:Connection>VM Network</rasd:Connection> <rasd:Name>eth0</rasd:Name> <rasd:MACAddress>00:50:56:b5:4c:64</rasd:MACAddress> </Item> should (if my understanding is correct) cause RHEV to export a virtio-net device to the guest. * It would be interesting to see the qemu command line that the guest ends up with. It should be obvious from the command line what device is being emulated. The guest will initially not have the correct driver installed. But once booted it will see the new PCI device, and it should then look in the HKLM\Software\Microsoft\Windows\CurrentVersion\DevicePath key (from the registry). This registry key should contain the path element C:\Windows\Drivers\VirtIO (and other paths too). * You could check the registry in the guest. In this directory there should be a compatible driver called netkvm.inf, netkvm.sys & netkvm.cat, and the guest should load this driver. * Check these files exist.
The import process works as designed. Network devices supported by rhevm (e1000/rtl8139) are kept intact, whareas unsupported devices (e.g. vmxnet) are converted to virtio. If the virtio ISO is attached during the import the drivers are prepared on the VM. So if desired, the network device can be changed to virtio manualy after the import.
Documentation Link: https://access.redhat.com/documentation/en/red-hat-virtualization/4.0/single/virtual-machine-management-guide#sect-Exporting_and_Importing_Virtual_Machines_and_Templates