Closed xaki23 closed 1 year ago
See journalctl in dom0, likely the exception message is there.
-- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab
I had the same issue, the journal says:
libvirtd[1766]: device not found: no device matching MAC address XX:XX:XX:XX:XX:XX found
Jul 04 16:07:46 dom0 qubesd[2404]: unhandled exception while calling src=b'dom0' meth=b'admin.vm.property.Set' dest=b'VMNAME'>
Jul 04 16:07:46 dom0 qubesd[2404]: Traceback (most recent call last):
Jul 04 16:07:46 dom0 qubesd[2404]: File "/usr/lib/python3.8/site-packages/qubes/api/__init__.py", line 288, in respond
Jul 04 16:07:46 dom0 qubesd[2404]: response = await self.mgmt.execute(
Jul 04 16:07:46 dom0 qubesd[2404]: File "/usr/lib/python3.8/site-packages/qubes/api/admin.py", line 265, in vm_property_set
Jul 04 16:07:46 dom0 qubesd[2404]: return self._property_set(self.dest,
Jul 04 16:07:46 dom0 qubesd[2404]: File "/usr/lib/python3.8/site-packages/qubes/api/admin.py", line 285, in _property_set
Jul 04 16:07:46 dom0 qubesd[2404]: setattr(dest, self.arg, newvalue)
Jul 04 16:07:46 dom0 qubesd[2404]: File "/usr/lib/python3.8/site-packages/qubes/vm/__init__.py", line 494, in __set__
Jul 04 16:07:46 dom0 qubesd[2404]: super().__set__(instance, vm)
Jul 04 16:07:46 dom0 qubesd[2404]: File "/usr/lib/python3.8/site-packages/qubes/__init__.py", line 262, in __set__
Jul 04 16:07:46 dom0 qubesd[2404]: instance.fire_event('property-pre-set:' + self.__name__,
Jul 04 16:07:46 dom0 qubesd[2404]: File "/usr/lib/python3.8/site-packages/qubes/events.py", line 195, in fire_event
Jul 04 16:07:46 dom0 qubesd[2404]: sync_effects, async_effects = self._fire_event(event, kwargs,
Jul 04 16:07:46 dom0 qubesd[2404]: File "/usr/lib/python3.8/site-packages/qubes/events.py", line 164, in _fire_event
Jul 04 16:07:46 dom0 qubesd[2404]: effect = func(self, event, **kwargs)
Jul 04 16:07:46 dom0 qubesd[2404]: File "/usr/lib/python3.8/site-packages/qubes/vm/mix/net.py", line 457, in on_property_p>
Jul 04 16:07:46 dom0 qubesd[2404]: self.detach_network()
Jul 04 16:07:46 dom0 qubesd[2404]: File "/usr/lib/python3.8/site-packages/qubes/vm/mix/net.py", line 346, in detach_network
Jul 04 16:07:46 dom0 qubesd[2404]: self.libvirt_domain.detachDevice(
Jul 04 16:07:46 dom0 qubesd[2404]: File "/usr/lib/python3.8/site-packages/qubes/app.py", line 103, in wrapper
Jul 04 16:07:46 dom0 qubesd[2404]: return attr(*args, **kwargs)
Jul 04 16:07:46 dom0 qubesd[2404]: File "/usr/lib64/python3.8/site-packages/libvirt.py", line 1343, in detachDevice
Jul 04 16:07:46 dom0 qubesd[2404]: if ret == -1: raise libvirtError ('virDomainDetachDevice() failed', dom=self)
Jul 04 16:07:46 dom0 qubesd[2404]: libvirt.libvirtError: device not found: no device matching MAC address XX:XX:XX:XX:XX:XX
Duplicate of #6493
This appears to be a duplicate of an existing issue. If so, please comment on the appropriate existing issue instead. If anyone believes this is not really a duplicate, please leave a comment briefly explaining why. We'll be happy to take another look and, if appropriate, reopen this issue. Thank you.
Qubes OS release
4.1
Brief summary
if a netvm crashes (and can not be restarted), it seems to be not possible to change the netvm of a running appvm to a working netvm. bonus: the error message is very misleading.
Steps to reproduce
creating a netvm and an appvm using it, starting both:
hard-stop the netvm, try to change the netvm of appvm, get non-helpful error:
restart old-netvm, try changing appvm-netvm again, works as expected:
Expected behavior
able to change netvm on an appvm.
Actual behavior
getting told "no such property: 'netvm'"
Educated Guess
seeing how this depends on whether the old-netvm is running or not, it probably throws somewhere when trying to reconfigure the expected-to-be-running old-netvm, and the throw is caught by a many-layers-up catch that translates it to the generic "huh?" error.
(proactive note for AD"needsdiagnosis"W ... figuring out where exactly it pops is like 90% of the fix.)