Disclaimer
I am far from being a tester, and I don’t have a Github account
Brief summary
I’m using Qubes 4.1 stable, updated to it from the early 4.1 betas.
More information
xen_version : 4.14.3
Linux 5.10.96-1.fc32.qubes.x86_64
Installed Packages:
qubes-manager.noarch 4.1.22-1.fc32
I found it possible to shutdown netVM, while the app qube to which that netVm is attached to, will still be runing.
I’m using regular sys-net -> sys-firewall -> sys-whonix -> anon-whonix setup.
While running anon-whonix and trying to restart sys-whonix via Qui-domains icon in the dom0 panel’s notification area, the request is refused with the notificiation:
Qube sys-whonix failed to shut down: There are other VMs connected to this Vm: anon-whonix.
which I guess is expected behavior.
Steps to reproduce
- Set shutdown idle TIMEOUT_SECONDS = 1 * 10 for the sys-firewall and restart it. Check if it shuts down after 10 seconds when no other qube attached to it is running.
- Start anon-whonix with the setup described above. Make sure all qubes are running.
- Open Qube manager.
- Right click to sys-whonix and choose
Restart.
Expected behavior
The request should be refused with the notificiation:
Qube sys-whonix failed to shut down: There are other VMs connected to this Vm: anon-whonix.
Actual behavior
Instead of refusing the request with the above notification, restarting of sys-whonix is allowed, although it is attached to a running anon-whonix.
Now, sys-whonix shuts down, then it attempts to start with the yellow ball indicator next to it in Qube manager. But, due to short idle timeout of 10 seconds, sys-firewall already shuts down, and sys-whonix isn’t able to start with the notification:
Qubes sys-whonix failed to start: internal error: libxenlight failed to create new domain ‘sys-whonix’
with the correspondent dialog box error message abou libxenlight ailed to create new domain ‘sys-whonix’.
Additional information
Although sys-whonix remains shut down, yellow indicator remains and it is not possible to take any action on sys-whonix in Qube manager, and the state of qubes isn’t automatically refreshed. So, Qube manager has to be closed and re-opened in order now to get actual state of sys-whonix - shut down and we are able to start it again from Qube manager.
Regardless of the sys-firewall’s short idle timeout of 10 seconds, restart is allowed as an issue not related to the previous fact. I used it to show that it ispossbile sys-whonix to be shut down while anon-whonix is still runnin (offline of course, but it is running)…
The problem I’m addressing
Especially Fedora has frequent updates, and updating templates and restarting all the VMs, in the chain (specifically those that aren’t based on template just updated) is cumbersome, not to tell when running large number of VMs. Restarting is enormously time consuming, and very often we need some qubes to stay opened, so we have to choose.
The solution I’d like
Just what this bug shows now: to be able to shutdown/restart at least netVM’s in the chain while putting other VMs offline during period of shutdown/restart. For example, if we shut down/restart sys-firewall, sys-whonix and anon-whonix to remain on, but offline.
The value to a user, and who that user might be
I haven’t investigated security implications of such a scenario, but if there weren’t be any, it would be one of the biggest time/life savers with Qubes for all users.