|Summary:||Network type shows both rt8319 and virtio when import guest from ova on rhv4.2|
|Product:||Red Hat Enterprise Virtualization Manager||Reporter:||mxie <mxie>|
|Component:||ovirt-engine||Assignee:||Dominik Holler <dholler>|
|Status:||CLOSED ERRATA||QA Contact:||Nisim Simsolo <nsimsolo>|
|Version:||4.2.6||CC:||ahadas, danken, dholler, juzhou, lsurette, mxie, mzhan, nsimsolo, rbarry, rdlugyhe, Rhev-m-bugs, srevivo, tburke, tzheng, xiaodwan|
|Fixed In Version:||ovirt-engine-4.3.0_alpha||Doc Type:||Bug Fix|
Previously, after importing a guest from an ova file, the Import Virtual Machine dialog displayed the network type as "Dual-mode rt8319, VirtIO", when it should have been only "VirtIO". The current release fixes this issue.
|Last Closed:||2019-05-08 12:38:08 UTC||Type:||Bug|
|oVirt Team:||Virt||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description firstname.lastname@example.org 2018-08-24 11:15:44 UTC
Comment 1 email@example.com 2018-08-24 11:16:34 UTC
Created attachment 1478464 [details] import-ova-network-2
Comment 2 firstname.lastname@example.org 2018-08-24 11:17:00 UTC
Created attachment 1478465 [details] import-ova-network-3
Comment 3 email@example.com 2018-08-24 11:17:59 UTC
Created attachment 1478466 [details] import-vmware-network
Comment 4 Dan Kenigsberg 2018-08-29 07:54:25 UTC
Can you attach a log collection? We'd need to see what is in the DB. Can you add a url to your OVA
Comment 5 firstname.lastname@example.org 2018-08-29 10:00:39 UTC
Attached vdsm.log and engine.log and please download ova files from http://fileshare.englab.nay.redhat.com/pub/section3/libvirtmanual/mxie/
Comment 6 email@example.com 2018-08-29 10:01:14 UTC
Created attachment 1479436 [details] engine.log
Comment 7 firstname.lastname@example.org 2018-08-29 10:01:52 UTC
Created attachment 1479437 [details] vdsm.log
Comment 8 Dominik Holler 2018-09-17 16:05:11 UTC
Arik, which behavior do you expect on importing a vNIC with ResourceSubType VmxNet3 in OVF? virt-v2v creates for an RHEL 7.5 VM a virtio vNIC. Engine creates a "Dual mode rtl8139, VirtIO" vNIC, which is not supported for RHEL 7.5 VMs by the UI. (OvfReader.getVmInterfaceType() returns null, NetworkInterface.setType(null) means "Dual mode rtl8139, VirtIO") To fix this bug, UI could allow "Dual mode rtl8139, VirtIO" vNIC for RHEL 7.5 or the import could create a virtio vNIC for RHEL 7.5 VMs.
Comment 9 Arik 2018-09-20 08:28:23 UTC
(In reply to Dominik Holler from comment #8) > Arik, which behavior do you expect on importing a vNIC with ResourceSubType > VmxNet3 in OVF? > virt-v2v creates for an RHEL 7.5 VM a virtio vNIC. > Engine creates a "Dual mode rtl8139, VirtIO" vNIC, which is not supported > for RHEL 7.5 VMs by the UI. > > (OvfReader.getVmInterfaceType() returns null, NetworkInterface.setType(null) > means "Dual mode rtl8139, VirtIO") > > To fix this bug, UI could allow "Dual mode rtl8139, VirtIO" vNIC for RHEL > 7.5 or the import could create a virtio vNIC for RHEL 7.5 VMs. I think we should go with the latter option, creating a virtio vNIC. I wouldn't limit that to RHEL though as we know virt-v2v installs virtio drivers on Windows guests.
Comment 10 Nisim Simsolo 2018-11-20 12:37:45 UTC
What is the expected behavior when importing OVA with E1000 adapter type? The current behavior is: VMware VMXNET3 and E1000E adapters are imported as VirtIO Vmware E1000 adapter remained E1000 after the import. This behavior is true for VMware VM/OVA import.
Comment 11 Dominik Holler 2018-11-20 13:04:52 UTC
(In reply to Nisim Simsolo from comment #10) > What is the expected behavior when importing OVA with E1000 adapter type? > > The current behavior is: > VMware VMXNET3 and E1000E adapters are imported as VirtIO > Vmware E1000 adapter remained E1000 after the import. > > This behavior is true for VMware VM/OVA import. From my developer's point of view this is good: if the vNIC type in the OVA can be mapped to a known vNIC type, it is kept, else it falls back on VirtIO.
Comment 12 Nisim Simsolo 2018-11-20 14:34:51 UTC
Verification builds: ovirt-engine-4.3.0-0.0.master.20181119094015.gitc05e510.el7 vdsm-4.30.2-11.git6c62ff1.el7.x86_64 libvirt-client-4.5.0-10.el7.x86_64 qemu-kvm-ev-2.10.0-21.el7_5.7.1.x86_64 sanlock-3.6.0-1.el7.x86_64 virt-v2v-1.38.2-12.el7.x86_64 Verification scenario: 1. Import VMware OVA (with complex configuration) with 10 NICs from different types (VMXNET3, E1000 and E1000E). 2. After import completed, verify all NICs adapter type is VirtIO. 3. Run VM and verify all NICs obtained IP from DCHP server. 4. Run lspci command and verify all NICs adapter type is VirtIO, for example: 00:0c.0 Ethernet controller: Red Hat, Inc Virtio network device 5. Repeat steps 1-5, but this time import VM from VMware.
Comment 14 errata-xmlrpc 2019-05-08 12:38:08 UTC
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-2019:1085