Generally we assume that a VM will remain running, even if its attendant netvm (i.e Net qube, the VM which is providing network to it) suddenly terminates.
However, some VMs are shutting down automatically when their netvm is terminated through qvm-kill. AppVMs shutting down unexpectedly is really bad and can lead to data loss!
This affects both Whonix 17 and 18.
using qvm-shutdown --force on the firewall VM still resulted in sys-whonix shutting down. A Whonix-based dispVM shut down once sys-whonix did, but multiple Whonix-based non-disposable appVMs did not.
shutting down sys-net did not trigger sys-whonix shutting down, but shutting down the firewall VM did.
Qubes wont allow to shut it down unless you agree that the VMs which relies on it will also going to shutdown, so terminating the netvm will for surely terminate others.
So if you want to change that, its qubes decision.
That dialog is a separate issue, which has already been discussed in the Qubes Forum thread. I am shutting down the VMs via command-line operations that bypass the mechanism you discuss. The unexpected shut downs still happen even when things are done this way. Non-Whonix VMs are not affected by this issue.
So it will trigger the shutdown of sys-whonix. Nevertheless, the whole mechanism of what you are seeing is qubes invented mechanism, Whonix is just a VM within Qubes ecosystem.
But that code is reviewed, maintained, and “controlled” by Qubes. I can open discussions / send pull requests (change discussions), but don’t have write access. [1]
qvm-shutdown / qvm-kill are Qubes tools in Qubes source code.
I am unaware of any Qubes feature that would let VMs (such as Whonix) configure different settings regarding shutdown/kill. I do not have any recollection of having (attempted to) develop a feature that changes standard Qubes qvm-shutdown / qvm-kill procedures.
[1] Write access was neither required, not requested, nor necessary.
FWIW, I can’t reproduce the issue from the original post. I can qvm-shutdown --force sys-firewall and qvm-kill sys-firewall without sys-whonix dying.
As far as I can tell, the dialog you cite is dom0 UI sugar. It results in dom0 sending a command to sys-net, sys-firewall, debian-personal, etc that they should all shutdown.
What I am doing is running (from dom0) either:
qvm-run sys-net “sudo reboot” or
qvm-kill sys-net
which both result in sys-net shutting down, without causing sys-firewallor debian-personal (from your example) to shut down.
The same happens if I issue the commands for sys-firewall: the sys-firewall VM shuts down, but debian-personal and sys-whonix do not.
However, if I issue the command for sys-whonix, then not just sys-whonix but also all connected Whonix Workstation-based VMs (dispVMs, or AppVMs) also shut down.
This behaviour appears limited to Whonix Workstation-based VMs. If I have a Fedora- or Debian-based VM that uses sys-whonix as NetVM, it does not shut down when sys-whonix does.
Looking at the Qubes logs, the shutdown is happening because the Workstation VMs experience a kernel panic when their connected NetVM shuts down. See logs here:
