It could improve performance.
Can you shows some benchmarks/comparisons?
When you run Qubes OS with low memory […]
I thought one would probably not RAM based disposables at all in such cases. What do you think?
PS: Next, I will add a vcpus option which makes also sense to me.
I wonder if we should rather focus on finding a way to run existing disposables in RAM, rather than piling up options.
We could simple add some date +%s watchdogs in the script but this would only allow us to measure the script execution time for some sections (qube creation / purge process). It will not help us in detecting RAM issues or quantifying RAM performances issues when reaching max RAM / balancing RAM / suspend, awake cases where this could impact performance.
No, I do not have a good and reproducible benchmark for RAM balancing issues. If someone has a good approach to do this please let me know. I also interested to get some reliable numbers. I would like to run some tests on my devices.
Beside the memmax settings discussion. How about some benchmarks on classical disposableVM vs. RAM disposableVM?
Well, yes if you keep all on Qubes defaults (max 4000 MB) you might run into RAM issues (with <= 16 GB) and therefore you might prefer the classical disposableVM. But if you reduce your qubes all to the (minimum) required RAM that is needed you could still benefit from RAM disposable. Consequently, having an option to set a maximum memory makes just sense.
Agree, adding options should not prio #1. Anyways, I do not see a problem - nor a ‘pilling up’ - in adding standard Qubes settings. I am ok to focus first on the creation and removing of disposable RAM VMs afterwards we can follow up the discussion to merge options to the code.
Just a quick note from the spectator’s lane to say that I’m genuinely impressed by how this collaboration is going. The ideas collaboration is great, but it’s the quality of the code collaboration that I really wouldn’t have predicted to happen in a forum topic (by that I mean, with no specialized tooling).
Seeing this makes me think: it seems like moving the Community Guides to the forum was a great idea.
Well done everyone, please keep going, I’ll keep cheering 
Or is there a way - an addon - to have a synced code view with a git repository? This would allow us a better collaboration and maintenance of the code itself.
Beside the memmax settings discussion. How about some benchmarks on classical disposableVM vs. RAM disposableVM?
The biggest question would be: what are we benchmarking?
The only speed up might be related to disk read/writes.
BTW, my main reason for creating this script was to reduce the disk writes to the SSD (thus hopefully making it last longer) 
Regarding the rest, I will come back with an update. I just need a some time.
Hi,
I have “cleaned” ALL traces of my old DispVMs (classic and RAM_Disposables) so that everything is clearer for me and I only see the traces RAM_Disposables. So let’s recap to make everything clear
Situation 1:
when I launch a RAM_disposable and close it BEFORE turning off my laptop, I am left with just two files
The file ~/.config/menus/applications-merged/user-qubes-vm-directory-dispXXXX.menu
The file /run/qubes/audio-control.dispXXXX
With the command "qvm-pool", ram_pool_dispXXX is no longer present.
Once the Laptop is turned off and relaunched, the file, /run/qubes/audio-control.dispXXXX is gone. Only the file ~/.config/menus/applications-merged/user-qubes-vm-directory-dispXXXX.menu is still here.
I also tried to do a qvm-kill dispXXXX and the result is identical Apart from the trace of this file, in my case, everything is perfect
Situation 2:
When I launch a RAM_disposable and I DO NOT close it BEFORE turning off my laptop, there are still many traces in the folders:
Could this be due to the “#Leave no trace on file system” section not running before Qubes-os is closed? That’s why I tried to close the DispVM with the qvm-kill dispXXX…
After that, is it possible to execute it before?, I’m not good enough to say it 
You can tell me "well, close them before turning off your laptop!! grrrr!! "lol. I’m ok, but in the evening I like to listen to music and do a shutdown -h 'time' to turn it off on its own. So what I’m doing right now is to run this command in the DispVM earlier than the one in dom0
I hope this description can help because it’s a very nice script and really useful 
Thanks for the additional info. Very good feedback.
I will consider all that for the next update.
Meanwhile, you can share your extra findings in this bug report:
It’s a good idea but the topic isn’t specific to your script Everything was said in the thread for the traces in the /var/ folder and subfolders. the traces in the /home/ folder and the ram_pool_dispXXXX come from your script and not directly from a Qubes-os 4.1 bug…
edit: I’ve also noticed that, when I don’t turn off dispXXX and I restart Qubes, it is, of course, still present but it behaves the same way. like an Appvm, as if I had created it with the “qubes tools”. For example, right now, I’m writing to you with the dispXXXX I created yesterday night and I didn’t turn it off before my laptop! lol
Wow, good catch!
I forgot about the “IdleActionSec=10min” that I set in order to try that automatic shutdown thing requested in another thread, so my laptop duly and unexpectedly shut down this morning… leaving two dispXXXX appvm’s which behave as you mentioned.
if you can’t remove ram_pool_dispXXXX with qvm-pool remove ram_pool_dispXXX. Delete your dispXXXX in qubes manager. Then you could remove it with qvm-pool. Then, remove the ~/tmp/dispXXXX. If it doesn’t work, use sudo umount ~/tmp/dispXXXX and you could remove the dispXXX folder
It’s a good idea but the topic isn’t specific to your script
All the traces you observe (except for the pools and ~/tmp/*) are a bug in Qubes OS. A deleted qube must not leave any traces, regardless of how it is created or deleted. The extra mile the script goes in order to clean up is necessary exactly because of this bug. It would be shorter if the bug did not exist. Hence my suggestion that you share the additional findings there.
Unless you don’t observe any traces with conventional DispVMs.
I will still see what can be done in regards to cleanup.
It’s done
Updated.
What’s new:
Reworked input parameters. Now you can use all properties as in qvm-create. Remember to edit your old shortcuts (if you have any), because they won’t work after the change.
The cleanup has been moved to a separate function with a trap to hopefully handle potential undesired interrupts. Unfortunately, this doesn’t seem to fix the issue of having qube remnants after a system shutdown while a RAM qube is running. For the moment I have no fix for this. If the OS sends a kill signal to the script, there is no way for the script to complete. The best thing to do is to close the RAM qubes before system reboot/shutdown.
Added a second script. It removes remnants from ANY non-existing qubes (not only RAM based but traditional too). Use with caution!
i @qubist
first, thanks for your work! 
I just tried the new 1st script, it works wonderfully, ALL files are well deleted! on the other hand, I can’t change the tempsize with “-s 5G” or with “–tempsize 5G” (maybe I don’t type it correctly?).
In line 43, it’s not “see man qvm-create for complete list…” instead of “see man qvm-prefs for complete list”? (It’s not very important but … )
Otherwise, for the 2nd script, I have a syntax error near the unexpected symbol near " < " .
I think i will the same error at line 75 too
I can’t change the tempsize with “-s 5G” or with “–tempsize 5G” (maybe I don’t type it correctly?).
It works for me:
user@dom0:~ > ram-qube -s 5G -p template=offline-min-dvm -c xterm
Running 'xterm' on rdisp4646
Checked in another terminal while the qube is active:
user@dom0:~ > qvm-pool i ram_pool_rdisp4646
name ram_pool_rdisp4646
dir_path /home/user/tmp/rdisp4646
driver file
ephemeral_volatile False
revisions_to_keep 1
size 5368709120
usage 8192
As you see, the size is 5G.
In line 43, it’s not “see man qvm-create for complete list…” instead of “see man qvm-prefs for complete list”? (It’s not very important but …
The possible properties are in man qvm-prefs.
Otherwise, for the 2nd script, I have a syntax error near the unexpected symbol near " < " .
I think i will the same error at line 75 too
Both scripts are verified using shellcheck and show no errors whatsoever.
I see no error during execution either.
Please run the problematic script with bash -x <script-name> and paste the error message with a few lines above it. Remember to hide any sensitive info before pasting.
To make sure we are both using the same code, first check:
$ sha256sum ram-qube remove-qubes-remnants
c63b40c8349c263fab798a4d20079578c3376837dc89e4002b03489f83ec6ef8 ram-qube
17472f717f392c4a8b94e743e7f46d8f5e63da154970ccecd87ee104e0a97529 remove-qubes-remnants
--tempsize
double “-”
She said she could not do it with “-s” either which is weird.
yes yes, that’s what I typed, it’s just copying where I made a typing error
It doesn’t match what I have, but it’s the same script.
BUT, the problem wasn’t with the scripts but with me!! I was using the “sh” command which worked very well with the other scripts! With the “bash” command, everything is perfect!
Really sorry! it must be tiredness
It’s so cute to see my /var/log/ folder so clean
@qubist Thanks you for your hard work the new script and the second script is working perfectly without trouble thanks you !
Just a little tips for people who doesn’t know that if you’re using KDE desktop in qubes you can launch your RAM VM disposable with a click instead of everytime use the command line in qubes.
You just have to write a second script like this :
#!/bin/bash
bash (name of the first script of qubist) -p template=X-dvm -c (command to launch) -p netvm=X
Now save the script on dom0 > right-clik on the disposable vm you want to launch with the script > go to Edit application > Application > You will see “command” click on “Browse” find the second script > click on “OK” and voila ! The script will work with the shorcut !
It’s so cute to see my /var/log/ folder so clean
I am working on an improved version. It finds even more files.