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

1 Like

-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.

2 Likes

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?

1 Like

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.

1 Like

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.)

1 Like

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

./RAM-only_DVM.sh -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

./RAM-only_DVM.sh -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.

1 Like

@Bearillo

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.

2 Likes

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).

1 Like

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

1 Like

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.

1 Like

@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:

2 Likes

Hello, after running the script that creates disposable (RAM-based) qubes:

[user@dom0]$ bash disposable -c firefox -p template=os-dvm-qube -p netvm=sys-firewall -p memory=2000 -s 400M -p label=purple

I have a block device (qubes_dom0-swap), as I understand it is a swap file:

[user@dom0]$ qvm-block
BACKEND:DEVID  DESCRIPTION      USED BY
dom0:dm-5      qubes_dom0-swap

After disabling disposable (RAM based) qubes, the block device (swap file) remains and disappears only after rebooting the computer.
I don’t understand why it is created, because there is enough RAM in dom0.

Executed the command before launching firefox disposable (RAM based) qubes:

[user@dom0]$ xl info total_memory
65232
[user@dom0]$ xl info free_memory
43357

Executed the command after launching firefox disposable (RAM based) qubes:

[user@dom0]$ xl info free_memory
39339

Please tell me how to make the block device (swap file) disappear after disposable (RAM based) qubes is turned off?

1 Like

The script only disables swapping to prevent disk writes. It does not create or manage the swap partition.

2 Likes

Yes indeed. I executed in the dom0 terminal:

[user@dom0]$ sudo swapoff --all

The block device qubes_dom0-swap immediately appeared, I will try to create a new topic to clarify this behavior. Thank you.

1 Like

Is there a guide on how to use this script?

1 Like

what is the most recent version of this script? Is there a way to combine all the

different parts into a single shell script and post it as a complete script?

That way it can easily be copied into /usr/local/bin/

what is the most recent version of this script?

It is in the OP. It will be that way until I find some time to put it in a versioning system.

Is there a way to combine all the different parts into a single shell script and post it as a complete script?

What different parts? The different scripts are for different tasks.

BTW, all your posts appear with weird line breaks (when using the forum by email).

1 Like

Is it possible to include the above mentioned scripts and modifications into unman’s

Github notes? I just have difficulty with following the different scripts that were added

in addition to the original script.

Is it possible to include the above mentioned scripts and modifications into unman’s

Github notes?

For that to happen, it would need @unman to do it. That would require him to agree to do that, to agree to update on potential updates to keep them up to date (to make sense of the whole thing), etc.

I don’t quite see why he would waste time with all that. Devs are busy people.

What exactly is the problem you are trying to solve with that question?