Really disposable (RAM based) qubes

No it isn’t, there is no M, the memory is in MB by default. I just try with it and it doesn’t work :slight_smile: :

qvm-prefs: error: Failed to parse property value as int

-p memory=400 -s 2G

However, I would use the opposite:

-p memory=2000 -s 400M

Reason: Firefox needs more RAM than storage, so no need to take so much from dom0 (-s) but better take from Xen (-p memory). You can use less than 400M if you configure your disposable template to mount ~/.mozilla on tmpfs, and thus offload even that to Xen.

1 Like

Would it be possible to make a template in which its goal is to create ram disposable qubes?
As in this template when using the App DVM launches a ram disposable qube. Is this possible?

RAM-based disposables are AppVMs (not DispVMs) cloned to a RAM mount point. The fact that they are based on disposable templates (which is a strange term, as it is neither a TemplateVM, nor disposable in any way) is just for conformity to the concept of conventional disposables with the idea to prevent mistakes.

I’m not fond of that naming convention either, and I think it leads to confusion. Sometimes someone has to specify something like “the template of the disposable template” to mean the actual templateVM.

And I’ve seen both disposable templates and named disposables named *-dvm, so when you see something like that in a menu it’s tricky to know what you’re getting. In the first case you could get either the disposable template as a (normal) AppVM, or a numbered disposable, depending. In the second, you get a disposable with a specific name. I personally name my disposable templates *-dvmt and named disposables *-disp. That still leaves the issue of knowing whether clicking on a *-dvmt menu item will open a numbered disposable or the disposable template itself.

(Now you CAN tell them apart, if you know the somewhat arcane menu convention…but you shouldn’t need to know it.)

Been playing around with the script a bit and there seem to be some problems:

./ -c xfce4-terminal -p template=debian-12-dvm-low-mem -p memory=1500 -s 500

will make it crash (qvm-clone: error: Got empty response from qubesd.), while

./ -c xfce4-terminal -p template=debian-12-dvm-low-mem -p memory=1500 -s 500M

works. So there’s an inconsistency: M can’t be added for the -p memory option, but has to be added for the -s option when trying to specify megabytes. This is because -s is handed off to the mount command, which uses the common convention (M designates megabytes), while -p memory is handed off to qvm-prefs, which defaults to MB…it’s really qvm-prefs that should accept values ending in m or M, but then again, it’s the script that takes values for different program’s parameters, so it could be argued that it should uniformize the formats through processing the input better.

Another example of input validation problems: if I put -s 2.5 or -s 2.5G, then it will crash after having created the PID file and thus fail to start up again until the user manually deletes it. Again, one could argue that mount should handle these kinds of values better, but the script also should clean up after itself. I see that the cleanup function does include the rm -f "${pidfile}", but since it’s mount that exits with an error code it doesn’t get called I think…probably something like mount [...] || cleanup would work here.


There is this comment in the code:

# TODO: Validate size value

This means, the concerns regarding it have already been considered and will be addressed somehow. Meanwhile, simply don’t use invalid input.

something like mount [...] || cleanup would work here.

Perhaps using ERR trap might be more elegant as a whole.

1 Like

And it’s followed up with

# Show error message if size exceeds
# available memory

So I wasn’t sure whether the number formatting issue was already known.

Perhaps, though set -e is still active at that point; I suggested || cleanup due to it already being used at two other places in the main function.

I’d also suggest updating the command line example to reflect the new Whonix template naming convention (workstation is spelled out now).

Could I rather make a shortcut as a App VM entry? Would this Be possible?

Could I rather make a shortcut as a App VM entry? Would this Be possible?

When the script creates the RAM-based AppVM, the qube will show up in your whisker menu just like regular AppVMs. When the qube is destroyed, it will disappear from there.

That’s all I know.

@disp10 I think you can’t but with the new appmenu, you could select to show the running online qubes on top of the applications. It’s very useful to find it quickly :slight_smile: