Created attachment 1407072 [details] logs Description of problem: Cannot start VM with <Empty> vNIC Again, new regression, cannot run VM with <Empty> vNIC - 2018-03-12 08:05:19,912+0200 ERROR (vm/f8abc451) [virt.vm] (vmId='f8abc451-ad7d-4916-ae0b-fca5cfa643bb') The vm start process failed (vm:940) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 869, in _startUnderlyingVm self._run() File "/usr/lib/python2.7/site-packages/vdsm/virt/vm.py", line 2832, in _run dom.createWithFlags(flags) File "/usr/lib/python2.7/site-packages/vdsm/common/libvirtconnection.py", line 130, in wrapper ret = f(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/common/function.py", line 92, in wrapper return func(inst, *args, **kwargs) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1099, in createWithFlags if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', dom=self) libvirtError: Cannot get interface MTU on '': No such device - 4.1(with 7.5) is OK , so it's our regression Version-Release number of selected component (if applicable): 4.2.2.2-0.1.el7 vdsm-4.20.20-1.el7ev.x86_64 kernel-3.10.0-860.el7.x86_64 libvirt-client-3.9.0-13.el7.x86_64 How reproducible: 100% Steps to Reproduce: 1. Try to run VM with <Empty> vNIC Actual results: libvirtError: Cannot get interface MTU on '': No such device Expected results: Should work
This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.
Francesco, that's one gap which vdsm needs to cover for NICs (with 4c8ed9e). fixNetworks() should handle it but engine is not sending NIC_BRIDGE - Arik, why? other than that this is currently covered by network device replacement
(In reply to Michal Skrivanek from comment #2) > Francesco, that's one gap which vdsm needs to cover for NICs (with 4c8ed9e). > fixNetworks() should handle it but engine is not sending NIC_BRIDGE - Arik, > why? > > other than that this is currently covered by network device replacement May also be related to https://gerrit.ovirt.org/#/c/88308/ - we need to verify that we don't break drive leases again
(In reply to Michal Skrivanek from comment #2) > Francesco, that's one gap which vdsm needs to cover for NICs (with 4c8ed9e). > fixNetworks() should handle it but engine is not sending NIC_BRIDGE - Arik, > why? > Different API, that's all - the engine sets the VDSM name of the network or empty string for empty vnic profile.
Then do not do that, there's a placeholder for that, and without it it's an invalid xml
Michael, do I understand correctly that it is the same flow as in bz 1478007 except that now the NIC is not defined with that 'dummyvdsm' network?
(In reply to Arik from comment #6) > Michael, do I understand correctly that it is the same flow as in bz 1478007 > except that now the NIC is not defined with that 'dummyvdsm' network? Hi Arik, Same flow, different error.
Verified on - 4.2.2.4-0.1.el7 and vdsm-4.20.22-1.el7ev.x86_64 with libvirt-client-3.9.0-14.el7.x86_64 libvirt-daemon-3.9.0-14.el7.x86_64
This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.2 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.