Complete traceback: Unable to complete install: 'Cannot get interface MAC on 'vnet%d': No such device' Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/create.py", line 2545, in _do_async_install guest.start_install(meter=meter) File "/usr/share/virt-manager/virtinst/guest.py", line 498, in start_install doboot, transient) File "/usr/share/virt-manager/virtinst/guest.py", line 434, in _create_guest domain = self.conn.createXML(install_xml or final_xml, 0) File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3647, in createXML if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=self) libvirtError: Cannot get interface MAC on 'vnet%d': No such device * * * Looks like the string is not interpolated correctly, i.e., no particular number for '%d' specification. This happens no matter what I try in the network selection, isolated network or NATs. Failed items from /var/log/audit/audit.log: type=VIRT_RESOURCE msg=audit(1509052795.922:3085): pid=5144 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=kvm resrc=net reason=open vm="generic" uuid=f62f80d0-bba2-4262-8fca-44207557e513 net=52:54:00:11:f7:e3 path="/dev/net/tun" rdev=0A:C8 exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=failed' type=VIRT_CONTROL msg=audit(1509052795.933:3092): pid=5144 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtd_t:s0-s0:c0.c1023 msg='virt=kvm op=start reason=booted vm="generic" uuid=f62f80d0-bba2-4262-8fca-44207557e513 vm-pid=-1 exe="/usr/sbin/libvirtd" hostname=? addr=? terminal=? res=failed' I am running virt-manager as a user, with following polkit rule: > polkit.addRule(function(action, subject) { > if (action.id == "org.libvirt.unix.manage" && > subject.user == "jpokorny") { > return polkit.Result.YES; > } else { > return polkit.Result.NO; > } > }); It has been working just fine until recently. $ rpm -q virt-manager libvirt-daemon > virt-manager-1.4.3-1.fc28.noarch > libvirt-daemon-3.8.0-1.fc28.x86_64
Consulting journal, there's one more item of interest, exactly before the first suspicious item from audit.log per above (all relevant records in audit.log are mirrored in journal as well): > error : virNetDevSetMACInternal:258 : Cannot get interface MAC on 'vnet%d': No such device
From further testing, it appears that further prerequisite is that there's already some other VM already running (and, perhaps implied, virtual network/s active) at the time I try to create a new machine.
Created attachment 1347347 [details] Generated XMLs of the VM and networks
I have the same issue. It will appear only when I try create a VM with 2 or more NICs. The same issue also appears after modification of existing VM. The modification ends successfully but when the VM starting it ends up with this traceback: Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 89, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/asyncjob.py", line 125, in tmpcb callback(*args, **kwargs) File "/usr/share/virt-manager/virtManager/libvirtobject.py", line 82, in newfn ret = fn(self, *args, **kwargs) File "/usr/share/virt-manager/virtManager/domain.py", line 1505, in startup self._backend.create() File "/usr/lib/python2.7/site-packages/libvirt.py", line 1069, in create if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self) libvirtError: Cannot get interface MAC on 'vnet%d': No such device Generated XMLs are in the attachments. Also the same error happens when I start the VM from virtsh so it is probably issue of libvirtd instead of the virt-manager.
Fixed for me from libvirt 3.9.0
Works for me as well after that update. Looking at https://www.redhat.com/archives/libvirt-announce/2017-November/msg00001.html this looks relevant: > - qemu: Reserve PCI addresses for implicit i440fx devices > Failing to do so causes the addresses to be considered usable by > libvirt, which means they could be assigned to more than one device > resulting in the guest failing to start. though no idea how much. Based on this observation and previously mentioned root cause in libvirt component [comment 4] that now seems certain, I am switching to it if someone from its maintainers can double-check (will close if there's no feedback till the end of the week).
Haven't attracted any attention of the maintainers so far, hence closing as WORKSFORME with the said version.