Why are disposable VMs/qubes based on AppVMs/Qubes?

Why are disposable VMs/qubes based on AppVMs/Qubes?

Why can’t a disposable Qube be directly based on a template Qube, rather that basing a disposable Qube on an app Qube which is based on a template Qubes?

You would still need to make a VM, the DVM is just a copy of a VM.

i find this logic and interesting question and I think it’s because of possibility to customize dispVMs by customizing dipsVM-template (that is AppVM). For example, take split-browser configuration…

That is fine. I’m wondering why a disposable has to be a copy of a copy? Why can it not be a copy of the original (i.e. the template)?

This sound very interesting. Would you mind elaborating?

It’s not a copy of a copy, you make a VM and each DVM is going to be a copy of that VM.

As I said. Check split-browser configuration.
Other example: I use minimal templates. It’s enough 400-800MB of RAM them to run smoothly. But, if a template firefox dispVM is 400MB, that wouldn’t be enough to run Firefox dispVM. So, how would you set 2048MB. Via dispVM-template. Maybe it’s not the best example, but I’m just giving you an idea that you can customize dispVMs and not messing with clogging templates, but dispVM-templates.

This gives some teeth to the explanation. Thank you very much @tempmail for this!

1 Like

In order to start the dispVM with some local data, like for instance a certain Firefox profile, these data have to be stored in /home or /rw, which is kept in an AppVM. Basing a dispVM directly on a TemplateVM would start the dispVM with an empty, or at least not correctly configured /rw and /home, while you can set these data in an AppVM as you like, and they will be used as such in the dispVM.

A related issue is the fact that this sometimes makes it very hard to talk about things, and sometimes hard to know what you’re doing when you’re clicking on the name of a disposable template in the menu.

Will you: start a new disposable based on that template? Or: Actually start the disposable template itself–i.e., run it as if it were any everyday appvm? (The pedantic will point out that it IS an appvm, which is absolutely true…but from the standpoint of the user, it’s not just an appvm.)

There IS a way to tell, at least in KDE menus (I think xfce (the default) is similar): The template itself, i.e., the link that will run the template like an AppVm, is titled Template (disp): <qubename> while the entry that fires up a disposable based on the templatr is Disposable: <qubename>. However, I had no end of grief remembering which was which for a while, until I finally just put the template (disp): entries in a menu subfolder named ‘run the template’. If you can’t organize your menu, you’re just SOL though I believe the xfce menu sensibly puts the template (disp) entries at the bottom since they won’t be used nearly as much (ideally, never but I happen to have special cases).

Of course all of this is about launching an unnamed disposable (disp1234). You can create a named disposable, too, based off that template. (It will show up in the menu as simply Qube: <qubename> and will look exactly like a regular appvm except for the icon.)

If you only ever want named disposables off of a disposable template, you probably don’t want the Disposable: menu entry at all (since it launches unnamed disposables). There’s a flag to set that in qvm-prefs or qvm-features (I don’t know it right now, but can look it up anytime I need it); with that flag set properly you won’t see Disposable: <qubename> in the menu. (However you can still run the template itself with the template (disp) menu entry.)

OK, so that can be pretty complex.

Now for an actual gripe: There’s a tendency to name both named disposables, and disposable templates, ending in -dvm. Unfortunately, that leaves me not knowing whether I’ll get disp1234 from starting it, or a qube of that name (i.e., the named disposable). [or you could even find yourself running the dvm template, it it is one.] Yes you can figure it out, but a name should tell you at a glance. -dvm as currently used, for example in debian-11-dvm and the names of whonix qubes, is ambiguous. I’ve personally gone to naming my dvm templates ending in -dvmt, and named disposables ending in -Disposable though I could have gone with -dvm. (My actual application qubes…i.e., the ones a user would use…have mixed case names, hence ‘-Disposable’. Oh, and sys-net, etc., is disposable even though there’s no suffix on it. Special case.)

Actually browser profile can be set via storing it in a /skel folder of a template

Thank you for this clear explanation @GWeck .

There is an open issue for allowing disposables to be based directly on regular templates without requiring an app qube to serve as a disposable template in the middle:

1 Like

That would simplify things greatly.

Rarely do I actually do something on the dvm template to configure anything.

Of course it would also make the comment I wrote above about twice as long, because now there would be three or maybe even four kinds of disposables from a user’s standpoint

Does anything really change?

You get the option to set the disposable flag when you create the appVM, which makes the process of crating a disposable more intuitive, but isn’t that the same as editing the settings yourself?

In XFCE menus (native or Whiskers), you’ll get disposable VMs twice:

  • One menu is called disposable: xxx-dvm:, which starts a dispVM based on that disposable template, running the selected application.

  • The other menu entry is called Template (disp): xxx-dvm, and that one starts the application in the template itself.

That helps a little, but I must admit that I still often use the wrong one. :frowning_face:

The new menu largely solves that problem, it has templates, appVMs, and sysVMs in different tabs.

The new menu should be default in 4.2.0, but you can manually install it in 4.1.2

That’s basically the same situation in KDE. It took a while to figure out, and now I avoid mistakes by filing the “run the actual template” entries in subfolders. [The fact is one almost never wants to run the template. But “almost never” isn’t quite the same as “never.”]

I’ve pretty much figured things out, but I just wanted to point out that though it does make sense, it ends up being complicated–I would hate to have to explain this to someone very new to computers–not without about a half hour of face-to-face time. (And some naming conventions that are in use, don’t help.) As such I think it might impede widespread adoption of QubesOS.

I wish I knew what to do about that.

I remember reading something over in the documentation (on qubes-os.org) where they had to write a sentence specifying that you wanted to do one step on the template vm of the disposable template. It was clear as day, but only because the writer took special effort to emphasize exactly what they wanted, and took no “of course they’ll know what I mean” shortcuts. (I went looking, and couldn’t find the example I am thinking of…I might edit later if I stumble across it.)

Under 4.1 I found Whisker menu more intuitive: Disposables are at the top of the menu, and templates at the end. Anyway, I’m actively using Favorites, since there I can rename entries to my liking. So, classic Q menu removed.