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!
So far I am primarily seeing this affect whonix-workstation-17 and whonix-gateway-17 based VMs, but I can’t rule out it affecting other VMs as well.
I dont use Whonix and have never seen this. I’d suggest it’s a
Whonix issue and raised as a bug there. (Though it may be a deliberate
design decision in Qubes-Whonix.)
I believe I have seen this on normal qubes, but it is extremely rare that I use qvm-kill, and not qvm-shutdown, which asks the user if it finds dependent qubes.
Added note: was probably in a no longer supported version.
If kill is really necessary, I (try to remember to) set the netvm temporarily to none for any dependents.
I do think it would be nice to have a ‘–temporary’ option for qvm-prefs, for using only on running qubes, to limit persistence of the change to the current instance.
It would avoid the need to remember to reset things when I have done with a temporary lockdown, etc. Probably too much complexity for a quite unusual use-case.
Using qvm-kill is probably excessive. You can always use “qvm-shutdown --force” to force the shutdown of a qube providing network to other qubes.
The qubes updater uses the same mechanism to restart sys-net, for example, after its template is updated.
I use qvm-kill a lot - I have it on a shortcut - I’ve not encountered
issues, and I have not seen the reported behavior
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Oh, good to know… I didn’t encounter the error either… but why do you use qvm-kill? Just because it’s faster to terminate volatile vms/qubes?
I’m using Whonix-17. I can’t find a Whonix-18 template in the Template Manager. Maybe that’s part of the problem – the template repos on my machine may be incomplete.
More testing:
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.sys-net did not trigger sys-whonix shutting down, but shutting down the firewall VM did.This sounds increasingly like a Whonix bug or design decision.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Upgrading to Whonix 18 did not fix the issue.
Posted to the Whonix forum:
When (for instance) shutting down sys-net while sys-firewall has it for its network VM, I’ve noticed in 4.3 it does ask first but I feel like I am being steered to tell it to shut down, which is the less safe option (perhaps because the button reads “OK” not “Yes”; “OK” is in my experience generally used to acknowledge messages, rather than approve a proposed action.
I’d like to suggest redoing that dialog so the default action is NOT to shut down the qube if other qubes are dependent on it.
That’s separate and unrelated… I am talking about something that happens without notifying the user, or giving the user a choice.
Your issue is undoubtedly Whonix - it could be a feature to ensure
that your downstream qubes dont run through clearnet if the upstream
disconnects from Tor. If so, it’s cack handed, and bad UX.
I’m sure the Whonix folk will resolve that issue.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
I use qvm-kill in scripts and I’ve also never seen this. I use it a couple of times daily in fact (like many many times, while working on kuhbs).
Might be a whonix paranoia thing where its scared that you might attach another netvm other than whonix-gateway, so it rather commits suicide than let you do that.
Whonix devs say it’s not their fault, it’s a Qubes issue:
http://forums.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/t/data-loss-inducing-issue-vms-terminate-unexpectedly-when-their-networkvm-shuts-down/23396/2
Since we’re at the “circular spiderman finger-pointing” stage of troubleshooting, maybe we should try to figure out what’s actually going on?
Where can I find the relevant logs that would explain how a given Whonix-based VM, or dispVM, is being told to shut down?
The onion forum is not available, so I cant comment on the reasoning
here.
If not a Whonix issue, then it is Qubes-Whonix specific. I thought
that the Whonix devs took responsibility for such issues.
I dont use Whonix so my troubleshooting will be limited.
Try in -
/var/log/xen/console/guest-QUBE.log
/var/log/qubes/guid.QUBE.log
/var/log/qubes/qrexec-QUBE.log
Obviously journalctl -r in dom0
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
Non-Onion link:
I shut down sys-whonix at 12:03 UTC. Two Whonix Workstation-based VMs were connected and shut down on their own. The dom0 logs for both VMs were identical. Here are the relevant log sections from both. It looks like shutting down sys-whonix resulted in a kernel panic in the connected VMs.
guest-VM.log:
[2026-07-11 12:03:28] [54021.205388] CPU: 1 UID: 0 PID: 63 Comm: xenwatch Not tainted 6.18.35-1.qubes.fc41.x86_64 #1 PREEMPT(full) ^M
[2026-07-11 12:03:28] [54021.205416] Call Trace:^M
[2026-07-11 12:03:28] [54021.205425] ^M
[2026-07-11 12:03:28] [54021.205433] dump_stack_lvl+0x5d/0x80^M
[2026-07-11 12:03:28] [54021.205447] vpanic+0x118/0x310^M
[2026-07-11 12:03:28] [54021.205461] panic+0x6b/0x6b^M
[2026-07-11 12:03:28] [54021.205475] ? xennet_disconnect_backend+0x1be/0x590 [xen_netfront]^M
[2026-07-11 12:03:28] [54021.205495] check_panic_on_warn.cold+0x1e/0x1e^M
[2026-07-11 12:03:28] [54021.205512] __warn.cold+0x9f/0xf1^M
[2026-07-11 12:03:28] [54021.205525] ? xennet_disconnect_backend+0x1be/0x590 [xen_netfront]^M
[2026-07-11 12:03:28] [54021.205546] report_bug+0xff/0x140^M
[2026-07-11 12:03:28] [54021.205560] ? xennet_disconnect_backend+0x1be/0x590 [xen_netfront]^M
[2026-07-11 12:03:28] [54021.205580] handle_bug+0x19e/0x260^M
[2026-07-11 12:03:28] [54021.205593] exc_invalid_op+0x17/0x70^M
[2026-07-11 12:03:28] [54021.205605] asm_exc_invalid_op+0x1a/0x20^M
[2026-07-11 12:03:28] [54021.205619] RIP: 0010:xennet_disconnect_backend+0x1be/0x590 [xen_netfront]^M
[2026-07-11 12:03:28] [54021.205644] Code: 00 0f 83 93 03 00 00 48 8b 94 dd 90 10 00 00 48 8b 4a 08 f6 c1 01 75 79 66 90 0f b6 4a 33 81 f9 f5 00 00 00 0f 85 f3 fe ff ff <0f> 0b 49 81 ff 00 01 00 00 0f 82 01 ff ff ff 4c 89 fe 48 c7 c7 e0^M
[2026-07-11 12:03:28] [54021.205691] RSP: 0018:ffffc90000ea7cc0 EFLAGS: 00010246^M
[2026-07-11 12:03:28] [54021.205707] RAX: 0000000000000010 RBX: 0000000000000000 RCX: 00000000000000f5^M
[2026-07-11 12:03:28] [54021.205728] RDX: ffffea000218ea00 RSI: 0000000000000000 RDI: ffffffff82731880^M
[2026-07-11 12:03:28] [54021.205749] RBP: ffff88800d9c2580 R08: ffff8880054c0f00 R09: 0000000080200019^M
[2026-07-11 12:03:28] [54021.205776] R10: 0000000080200019 R11: ffffea0000c05000 R12: 0000000000002580^M
[2026-07-11 12:03:28] [54021.205797] R13: ffff88800db98300 R14: ffff8880050c5ac0 R15: 0000000000000000^M
[2026-07-11 12:03:28] [54021.205822] xennet_remove+0x1e/0x80 [xen_netfront]^M
[2026-07-11 12:03:28] [54021.205840] xenbus_dev_remove+0x71/0xf0^M
[2026-07-11 12:03:28] [54021.205853] device_release_driver_internal+0x19c/0x200^M
[2026-07-11 12:03:28] [54021.205870] bus_remove_device+0xe8/0x1b0^M
[2026-07-11 12:03:28] [54021.205883] ? device_remove_attrs+0xa1/0x100^M
[2026-07-11 12:03:28] [54021.205900] device_del+0x160/0x3e0^M
[2026-07-11 12:03:28] [54021.205914] ? __pfx_xenwatch_thread+0x10/0x10^M
[2026-07-11 12:03:28] [54021.205931] device_unregister+0x17/0x60^M
[2026-07-11 12:03:28] [54021.206178] xenbus_dev_changed.cold+0x54/0x71^M
[2026-07-11 12:03:28] [54021.206197] ? __pfx_xenwatch_thread+0x10/0x10^M
[2026-07-11 12:03:28] [54021.206213] xenwatch_thread+0x92/0x1c0^M
[2026-07-11 12:03:28] [54021.206227] ? __pfx_autoremove_wake_function+0x10/0x10^M
[2026-07-11 12:03:28] [54021.206244] kthread+0xfc/0x240^M
[2026-07-11 12:03:28] [54021.206257] ? __pfx_kthread+0x10/0x10^M
[2026-07-11 12:03:28] [54021.206270] ret_from_fork+0x158/0x170^M
[2026-07-11 12:03:28] [54021.206283] ? __pfx_kthread+0x10/0x10^M
[2026-07-11 12:03:28] [54021.206296] ret_from_fork_asm+0x1a/0x30^M
[2026-07-11 12:03:28] [54021.206311] ^M
[2026-07-11 12:03:28] [54021.206683] Kernel Offset: disabled^M
guid log:
Icon size: 128x128
libvchan_is_eof
Icon size: 128x128
domain dead
Failed to connect to gui-agent
qrexec log:
Unknown capability x-canonical-private-icon-only detected
Server capabilities: body markup true, persistence false
Entering loop
2026-07-11 12:03:29.612 qrexec-daemon[11808]: qrexec-daemon.c:1793:main: qrexec-agent has disconnected
domain dead
2026-07-11 12:03:29.617 qrexec-daemon[11808]: qrexec-daemon.c:1649:handle_agent_restart: cannot connect to qrexec agent: No such file or directory
2026-07-11 12:03:29.617 qrexec-daemon[11808]: qrexec-daemon.c:1795:main: Failed to reconnect to qrexec-agent, terminating
2026-07-11 12:03:31.295 qrexec-daemon[11903]: process_io.c:250:qrexec_process_io: vchan connection closed early (fds: 5 6 -1, status: -1 -1)
Leaving loop
2026-07-11 12:03:36.427 qrexec-daemon[11908]: process_io.c:250:qrexec_process_io: vchan connection closed early (fds: 4 4 -1, status: -1 -1)