Paused and hidden disp qubes

Atrate · February 1, 2026, 1:39pm

Allow adding some kind of "alias" or "name" to unnamed disposables

opened 12:33PM - 12 Dec 25 UTC

C: core ux P: default

### The problem you're addressing (if any) When using a lot of unnamed disposab…les, I sometimes find myself wondering where I should paste some text, copy some file, etc. : is it *disp3027*? *disp111*? *disp4186*?... ### The solution you'd like I would like a way to give an "alias" ("name" or "label" are currently used terms) to unnamed disposables. This is what I want to do in the end: * When switching between windows, I want to see some title like `[disp1234-download-pdf]`, `[disp1234%download-pdf]` or `[disp1234 "download-pdf"]` or something else, where `disp1234` is the name of the disposable and `download-pdf` is my custom "alias". * When looking for files in `~/QubesIncoming`, I would like to see a folder name like `disp1234-download-pdf` (in that case, I think that using a space could be painful?) * When opening the Qubes Domain widget, I want to see the qube as `disp1234-download-pdf` or `disp1234 (download-pdf)` * Same thing in qube listed in Qubes Device widget, in Qubes Appmenu, in the policy pop-up asking to choose a qube, in `Qubes Backup tool` * Qubes Manager, `qvm-ls` could use a new "alias" column * It could be nice to be able to use the "alias" in `qvm-` tools instead of `dispXXXX` but it might be difficult to handle duplicates ([as pointed out by alimirjamali](https://github.com/QubesOS/qubes-issues/issues/10462#issuecomment-3640827904)) ### The value to a user and who that user might be * Less cognitive load * Lowering the risk of mistakes between unnamed disposables (resulting in security or privacy issues) ### Completion criteria checklist (This section is for developer use only. Please do not modify it.) ### Note A first version of this feature request was proposed as #10462. This version takes into account the comments made by @alimirjamali

github.com/QubesOS/qubes-issues

Allow renaming unnamed disposables

opened 07:42AM - 10 Dec 25 UTC

closed 12:33PM - 12 Dec 25 UTC

parulin

R: duplicate C: core ux P: default

### The problem you're addressing (if any) When using a lot of unnamed disposab…les, I sometimes find myself wondering where I should paste some text, copy some file, etc. : is it *disp3027*? *disp111*? *disp4186*?... ### The solution you'd like It would be great to be able to rename an unnamed disposable. Some of the possible solutions to achieve that are: * Allowing renaming in the Settings of the unnamed disposable * Adding a menu entry in the Devices widget ("Rename disposable") only for unnamed disposables * Allowing the following command: ``` qvm-prefs --set dispXXXX name some-custom-name ``` * or creating a new CLI tool `qvm-rename-disposable` or whatever * same thing with the Python API * providing a way to create a disposable and be prompted about the name It might be a good idea to force a prefix like `disp-` before the custom name? ### The value to a user and who that user might be * Less cognitive load * Lowering the risk of mistakes between unnamed disposables (resulting in security or privacy issues) ### Completion criteria checklist (This section is for developer use only. Please do not modify it.)

github.com/QubesOS/qubes-issues

Preloaded AppVMs

opened 09:45PM - 22 Aug 25 UTC

Atrate

C: core P: default

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) ###… The problem you're addressing (if any) The implementation of preloaded disposables (#1512) is really nice, and in my case, I found it even better than expected - they use (almost literally) no CPU time as well as very small amounts of memory compared to their maxmem value. This gave me another idea: why not preload AppVMs? There's AppVMs that I frequently launch on OS startup (or just launch and shut them down periodically). Some of them have quite high maxmem values and I can't really do anything about that. This means that launching them on boot immediately "locks me out"* of a lot of memory, especially if I do not in fact use those AppVMs. This also applies to ServiceVMs, like VPN qubes, which get launched and shut down quite often in my case. * I really try to avoid memory ballooning taking place, as it causes a lot of memory fragmentation => a lot of performance issues ### The solution you'd like For this case, preloaded AppVMs would be perfect. I could choose, say, 5 different Qubes (some AppVMs, some ServiceVMs) that I want preloaded at boot (and whenever they are shut down as well) and be able to access them way more quickly without sacrificing a lot of memory in the process. This would also satisfy the use case of #10177, which may be completely technically unfeasible. ### The value to a user and who that user might be Anyone who wants snappier operation in qubes can benefit. ### Completion criteria checklist (This section is for developer use only. Please do not modify it.)