Whonix-ws-16-dvm ignores default DispVM template


No syntax error. The value was set as expected.

What do you mean “name-of-your-vm”? The goal is to set the value for all DispVMs based on whonix-ws-16-dvm template.

I did try what you suggest like this:

qvm-features whonix-ws-16-dvm whonix-default-dispvm 1


qvm-features whonix-ws-16-dvm whonix-default-dispvm 0

Nothing changed.
Any other ideas?

Should I ask somewhere else (on whonix forums or other)?

Since this is a dom0 question, no need to use the Whonix forums. This is primarily a Qubes issue.

In your case based on what you wrote the name of your vm is probably minimal-offline-dvm.


qvm-features minimal-offline-dvm whonix-default-dispvm 1



qvm-features minimal-offline-dvm whonix-default-dispvm 1

Nope. That still doesn’t give the desired result.

You’d need to add debug output to that python script (print()) to see what’s happening. The file location in dom0 is:


OK. On my (up-to-date) 4.1.2 system the directory is python3.8 (not 3.11). I don’t know if that matters. Just mentioning it.

So, I added print(default_dispvm) inside on_domain_add function, properly indented, right after all the checks related to its assignment, and ran:

user@dom0:~ > qvm-run -v -q -a --service --dispvm=whonix-ws-16-dvm -- qubes.StartApp+janondisttorbrowser
Running 'qubes.StartApp+janondisttorbrowser' on $dispvm:whonix-ws-16-dvm

IOW, it doesn’t output anything. I don’t know how output is handled internally among those Python scripts but it obviously doesn’t show on CLI.

Then I tried hard coding default_dispvm and logging it by adding this at the very end of on_domain_add:

             default_dispvm = 'd12-m-dvm'

Even that didn’t help. The value of default_dispvm is not visible in any log either and the default dispvm is still whonix-16-ws-dvm.

Another thing which caught my attention is that this script refers to template.features. I don’t know if that “features” is the same “features” which qvm-features manipulates but it seems worth noting because qvm-features doesn’t seem able to change default_dispvm. Only qvm-create and qvm-prefs can do that and there is no “craete” or “prefs” anywhere in the Python script.

So far, the only way through which I was able to manipulate this successfully is through the bash script for creating RAM based disposables which does it through qvm-create.

Please let me know if there is a way to fix that Python stuff.

1 Like

In that case, we need a Qubes developer to give a hint on how to enable print debug output.

Another hacky option in these cases is writing the debug output to a log, maybe quick and dirty somewhere in the home folder.

In that case, we need a Qubes developer to give a hint on how to enable print debug output.

How do we invite one here?

Another hacky option in these cases is writing the debug output to a log, maybe quick and dirty somewhere in the home folder.

How to do that?

Did you try with fedora based dispVM? It works for me, but I disabled default dispVM, and rather prefer dialog box to choose dispVM when “view/edit in dispVM” is clicked.

# qubes.OpenInVM          *          @anyvm           @dispvm	allow
qubes.OpenInVM          *           @anyvm          @anyvm      ask

in a correspondent RPC policy.


Did you try with fedora based dispVM?

Yes, right after reading your reply, I have set default_dispvm (yes, through UI settings) of whonix-ws-16-dvm to Fedora based DVM and then it works. I have not touched any policy.

Then I tried the following:

In Qubes Global Settings I set the disposable template = none (it was d12-m-dvm).

After that, setting d12-m-dvm as default_dispvm of whonix-ws-16-dvm worked too.
Then, I went back to Qubes Global Settings and reverted the change, setting default disposable template again to d12-m-dvm, and started a whonix-ws-16-dvm based DispVM. Result: works as expected with default_disvmp=d12-m-dvm.

IOW, there doesn’t seem to exist any network leak protection at all. The problem is that is seems impossible to use the globally default disposable template without the gymnastics from above.

I wonder if this needs a bug report.

Such things made me use fedora everytwhere, except cacher-ng of course. Qubes is just designed based on and for Fedora.

IIUC, the issue is not Fedora or non-Fedora. It seems related to default global disposable setting.

What is cacher-ng? (please link to whatever doc/thread is relevant, thanks)

1 Like

I know that a numbered disposable, when launched, invariably makes its own dvm template the default dvm, regardless of what you have the global default set to. It also doesn’t matter what the template’s dvm is.

OK, that’s probably very confusing to read. So, let me do an example. I have a template with firefox (firefox-tmpl). I create an appvm and make it a disposable template: firefox-dvmt.

I then create another template with document viewers on it, global-tmpl, and base global-dvmt off of it; I want global-dvmt to be the default dispVM for everything. It’s isolated from networks and has apps needed to view documents on it.

So I set the global dvm to be global-dvmt. Normally that’s now the disposable template for qubes. Appvms will use it. It’s even the disposable when I am running firefox-dvmt itself. (In qubes-mgr firefox-dvmt’s default dispvm is global-dvmt.)

But when I launch a disposable disp1234 off of firefox-dvmt, disp1234’s disposable is firefox-dvmt, NOT global-dvmt. There’s no way to prevent this because the qube is created right then and there. You have to go into its settings and change it to global-dvmt, AFTER you start it.

I really don’t like this. Because I probably didn’t install document viewers and the like on firefox-tmpl, thinking that that was global-tmpl and global-dvmt’s job. The way this is set up requires you to install document viewers and the like on the same template as your browser.

If you have an e-mail client (rather than using webmail through a browser), that client is probably a regular AppVM (so it will remember things like your email inbox from one run to the next), so it’s not that big an issue then–attachments will go to global-dvmt. But even so, what about documents you download off of a website?


Interesting. I don’t experience what you describe (using Qubes 4.1.2) with non-whonix disposables.

There’s no way to prevent this because the qube is created right then and there. You have to go into its settings and change it to global-dvmt, AFTER you start it.

There is a way. You can achieve this, if you follow what I described above:

  • In global settings, set disposable template = none
  • In your DVM (firefox-dvmt), set default_dispvm=global-dvmt

The other option is to use the script for RAM based disposables.

what about documents you download off of a website?

I proceed with those like this:

If I am not going to open the file (but just store/copy it), in the AppVM, I have default action for the file type called “nothing”. It is a simple bash script I place in /usr/bin:


This prevents me from accidentally double clicking on a file in Thunar and opening it in the AppVM. Perhaps there is a way to make this the default action for all files in the template itself, so that I don’t need to do it in every AppVM, but I still have not done this.

For files which I am willing to open, I either right click and “View in VM”, or I have default action qvm-open-in-dvm which opens the file in my version of your firefox-dvm based disposable. Yes, it works. Currently I am working on customizing the default action, so that files open in RAM based offline disposables. Then even RAM disposables will be able to open files in other RAM disposables.

But that’s the point. You shouldn’t have to go through those gyrations. I’m agreeing with you in comment #14 that it might be a bug.

Also, I described a specific use case where (it seems to me) the actual behavior is nonsensical. So, is this deliberate? If so it’s a “feature” rather than an out-and-out bug,* but I think it needs to change either way.

As for the rest of what you wrote, thanks, it’s good info.

Note* Bug: The code doesn’t behave as the developer(s) intended. Feature: The code behaves as the developer(s) intended, but you think the developer(s) shouldn’t have intended it that way–in other words you’re arguing with their design decision, not their implementation.

I’m guessing you opened that. If so, thanks!

Interesting that it was indeed a deliberate decision. It makes no sense to me.


In fact a common complaint is a dvm that cannot handle a file, so it hands it off to its default disposable. That can loop forever if it is its own default disposable. I could sometimes be racing to kill dvms faster than they’re being created when this happened.

This seems to encourage that to happen, on top of all of our other complaints about it.