I created a schematic since I am a visual learner to understand the type of qubes that are being used.
Updated 14/09/2024
Feel free to correct any mistakes
I created a schematic since I am a visual learner to understand the type of qubes that are being used.
Updated 14/09/2024
Feel free to correct any mistakes
Cocerning PV, one should mention that they were replaced due to security issues (i.e., they’re insecure).
Doesn’t PVH also use VT-x and VT-d?
Interesting
it is missing named disposable
I don’t think it supports PCI passthrough.
Isn’t it a alternative name for Disposable VM? (Maybe I made the synonym color little to light-grey)
Unlike just disposable, named disposable’s config can be saved in a different state from its template. Also, you can only have one running simultaneously (no automatic name generation, like disp1234
)
Apart from that, they are useful in scripts or for other tasks that benefit from their name being static, like sys-net, sys-usb, sys-firewall, etc.
yes, this make it easier to use a disposable daily from a working appvm (which becomes a disposable template), and you can reuse this disposable easily for some operation.
A use case I have is a web browsing disposable that lives until I close my system, all links from other qubes are opened in it.
Is this connected? I thought VT-d was a general virtualization technology in Qubes.
No, VT-d is Intel’s implementation of IOMMU: the technology that allows us to pass PCI devices.
Updated 14/09/2024
I think you’ve misinterpreted how named disposables work.
According to the documenation:
Like a regular disposable, a named disposable always has the same state when it starts, namely that of the disposable template on which it is based.
App qube must be a disposable template for a named disposable to inherit its filesystem. Just like a regular disposable, named disposable has no filesystem persistence. The main difference is that named disposables have static names to them.
This (among other things) means that named disposable may be configured differently compared to its template (for instance, firewall settings or devices passed through). Although regular disposables may also be configured differently from their templates, this configuration can only be done after the disposable is created and will not be saved upon its shutdown.
Cool to see a diagram like this, but I think virtualization technologies in standalone actually apply to all VM types. It’s just that Standalones are often for custom ISOs which need HVM out of the box. but you can just as easily create a PVH Standalone from a regular qube. PV does exist but is doscouraged. And a fun fact is that dom0 AFAIK still runs in PV. But that doezn’t carry security issues.
If you are a visual learner, then qvm-ls-mermaid may interest you:
Objective: Be able to visualize your configuration using qvm-ls-mermaid like this: qvm-ls-mermaid/examples/1.png at master · 3hhh/qvm-ls-mermaid · GitHub , but without trusting it in dom0 qvm-ls-mermaid is written by 3hhh/tripleh and can be installed in dom0. And while we don’t specifically distrust tripleh, we don’t necessarily trust him either. (Sorry @tripleh ! ). The idea is that instead of doing a security review of each line of code in qvm-ls-mermaid, and …
For me, this was the best I needed to comprehend Qubes
Qubes is a security-oriented, free and open-source operating system for personal computers that allows you to securely compartmentalize your digital life.
@marsupial I just want to thank you for this schematic. I am sure it will help many Qubes newbies to better understand the templateVM appVM disposalableVM relationship and dependencies.
I hope it will be in the official docs soon!
exactly, named disposables are just a single disposable made from an AppVM, you can’t start it twice but as it’s named, it won’t stop when you quit all applications you started on it, and it make scripting easier / possible.
Other, a non named disposable will just create a new disposable from an AppVM but a named like dispXXXXX, if you close all GUI apps, it’s stopped.
It’s important to point out that even disposable data are written to disk before being discarded when the disposable stop, there is already a mention that things do not all happen in ram, but it should be more exhaustive: all things happens on disk This mean it’s theoretically possible to recover old data of disposables.
There is a setup to run some qubes entirely from RAM but it’s not straightforward.
@marsupial could you please copy your drawing to:
draw.io is free online diagram software for making flowcharts, process diagrams, org charts, UML, ER and network diagrams
It would help us to contribute and update. Furthermore, it would be aligned with Qubes OS architecture diagrams.
Qubes OS architecture diagrams for use in articles, posts and docs
There is a setup to run some qubes entirely from RAM but it’s not straightforward.
I use this script from running disposable entirely in the ram
Hi, While researching, I found @unman’s GitHub repo and another user’s improvement of the original bash script. After noticing some issues (with log paths), I allowed myself the liberty to fix them and add further flexibility to the script. One essential new thing is that no log files are saved on the file system at all as they exist only as symlinks to /dev/null. Additionally, now names are not fixed and one can use the script based on one’s own templates and preferences. I still don’t know h…
Hence the “not straighforward”
Hey what program did you use to make that? I like making schematics like that but I use Inkscale so I have to draw my own arrows n stuff yours looks like the program does it for you
@Quben Maybe you have not seen my recommendation.