How much disk space do Templates take up?

In general or as the median, how much do the usual Templates bases take up in disk space on the hard drive?

I am trying to map out all the qubes I will be using, and am considering making multiple templates of not just the regular Debian and Whonix but also installing Vanilla OS among others.

I read that Vanilla OS needs 50G of hard disk, but that’s only for the base Template not for every template copy that is using the base template as the persistent Template right? Or will every Template copy take up 50G each?

Also, while on the subject, how many Gigs or MegaBytes does the Vault Template take up? And when I make a Vault Template copy is it using the disk space allocated already or did I just double it by cloning it as another template from the base?

Don’t be afraid to play with Qubes OS to discover this by yourself:

Create a clone in Qube Manager or with the following command:

qvm-clone <ORIGINAL_VM> <CLONE_VM>

Example with fedora (but replace the names by what you want):

qvm-clone fedora-39-xfce fedora-clone

Then, run the clone template once and, in Qube Manager, check the Disk Usage column of the two templates. I think that the numbers will be quite the same.

Note: my advice to “play with Qubes” doesn’t apply to installing Vanilla OS or templates that are not officially supported by Qubes. Right now, according to my poor knowledge of the whole thing, my own decision is not to use them.

1 Like

I get your point and sentiment but for this particular machine I don’t want to have to babysit my mom’s computer for her first month on Qubes, so I am trying to make reasonable accurate guesses so I don’t have to hear her complain assuming the laptop or OS is broken when in fact I just didn’t realize a qube needed more space or RAM allocated. I also don’t feel like driving 3 hours either since I will NOT open it up to remote access due to our shared Threat Model, so if I don’t guess right that will be a 6 hour round trip drive.

As for the noted opinion on unofficial build distros as templates bases,

I am willing to take a chance at some things.

Here is my logic behind wanting to utilize Vanilla OS:
I heard VanillaOS is an immutable OS, meaning that hypothetically the OS when deployed cannot be altered. Which IMHO would add another extra layer of security for preventing persistence if the qube was ever compromised,
1st it is a VM on Qubes,
2nd it can be a disposable qube that references the base template for VanillaOS,
3rd the qube itself should hypothetically be difficult to alter not just in any attempts to gain persistence but also in any attempts to break through to realize it is a VM

I mean from what little I know I figured utilizing an Immutable OS would be even extra on a QubesOS VM

Unless I am misunderstanding or am unaware of something in how this all functions

So correct me if I am wrong,

from what I now understand reading through various online source including this Forum

When I have a base Template with an OS on it to VM,
then I open that VM,
say that OS requires a minimum of 50G hard drive disk space.

Then that means if I want 2 different VMs using the same OS Template. Both of those VMs will require while at
as well as
when actively started as a “start qube”
each will be taking up 50G hard drive disk allocation.
Thus, 100G disk space used in total for 2 separate VMs using the same OS Template which requires 50G worth of space each?

Is that correct or no?

this is misconception, I wrote an extended blog post about immutables OS

1 Like


  • immutability is often associated with security benefits, I don’t understand why. If someone obtains root access on your system, they can still manipulate the live system and have fun with the /boot partition, nothing prevent them to install a backdoor for the next boot.

@solene blog source

So there is nothing to prevent the altering of a base template? Like true immutability doesn’t actually exist?

Then hmmm, can a VM have one of those boot hash checkers then? Not sure what the proper name is called. Where it checks if it has been changed or not at every boot, but do this on a VM “start” rather than a real boot on bare metal. Does that exist? To warn if a qube you wanted unaltered was altered in a fundamental way, to know as a warning if that persistent qube is corrupted and/or compromised

Why I am looking for something that does such a thing:
• I and even my mom wants persistence in some qube VMs so to author documents before sending them off in email or uploading to a website. So basically all the qube will be used for would be

  1. web surfing
  2. document creation, uploading/downloading
  3. image uploading/downloading
  4. video uploading/downloading

Such activities do carry some malware risk, so since I don’t want the qube to be disposable the risk increases which is why I am looking for an unaltered state (not sure if this is what “sateless” means or not). Unaltered, except for of course being able to set “settings” in the browser for some security features turned onto “on”, as well as being able to read and write to user files BUT not to any other directory or file as well as not able to run any executions outside of the default apps to “launch” on click of course.

Does this solution not yet exist then?

For true peace of mind I have to incorporate Disposable VM qubes then???

Please let me know, thanks

“any linux distribution with regular btrfs snapshots you could select a snapshot at boot time.”

Can this be done on a qube VM boot/start? Without having to be in a disposable qube?
Like can I have persistence for files and folders in a user directory, but have everything else revert back to a snapshot like the Template would be used for a disposable to re-initiate on start?

But also still my main question still stands

Does an OS iso Template take up space only once per Template created as a base
does it take up space per each qube VM created using that base Template?

I would assume it is per each VM Qube created … but I am merely guessing

Okay what about using both Firefox Containers as well as other OS app containers inside a qube VM running Clear Linux OS?

Would that assist to defend my mom and I in our Threat Model situation?

Qubes OS handle this differently, every time you boot an AppVM this is what happens:

  • a new disk derived from the template is generated, it will contain changes against the template and only store the changes temporarily, it’s deleted after the qube is stopped
  • a new disk derived from the AppVM storage is generated, it contains changes, upon stop, the derived disk n-1 is merged with the main storage, this is configurable and basically you have 1 snapshot of your system out of the box so you could revert changes done in the last AppVm runtime

this is not immutability here, it’s the world that is recreated at every boot

this is more os so already done with the different delta disks of each qubes (see qvm-volume), there is an official documentation page for this stuff

only once, if you have one template + 10 AppVM using it, you will have one disk for the template and 10 disks for the AppVM + 10 disks for temporary changes in the AppVM template area that are discarded at every boot


1 Like

this doesn’t prevent a malware to write something to the AppVM persistent storage or use /rw/config/ if the permissions are wrong or passwordless root.

This doesn’t help much with regard to security, but it helps keeping the system sane

1 Like

Oh ok

So is a SuDo password my best defense here then?

Having a password to become root (either a root password and no passwordless sudo, or sudo with a password and no way to log as root without a password) is better indeed.

But it could still be possible to add a rogue binary and auto start it with the appVm, just add an entry in ~/.config/autostart/ for instance

1 Like

Is there anything I can implement to stop or at least mitigate that weakness?

I hope it doesn’t require me to do BASH stuff,
I came across this (which is not the same but maybe “cat” is part of it if an attacker wants to map or something I don’t know just guessing)

btw I tried signing up to a Security Forum but the Security Forum flags the domain of the privacy email I use :frowning: I will likely try making an alias on an email that allows aliases later and try those domains. That bites though, as the probability email suite I am currently using as a mobile phone solution is great and their use cases involve domestic violence survivors so I am upset places are starting to block that email service … but yeah I need to go bug a security forum one day after I finish setting up the QubesOS laptops so I can ask these other questions and even maybe get help with 2 different firewalls I have never used before but will be doing a crash course in here soon upon resetting up a network that this time will be hardened

Oh how about this!?!

Maybe before putting the system online, I make copies of those “binary files” inside the Qubes Vault as well as an offline backup and then every so often I run a check to compare the current running version of those “binary files” with the backed up ones used as a reference???

Will that work as a mitigation practice?

source from how I got this idea:

Is there a program/app that does this on Linux already?
If not,
what script stuff do I have to kind of learn to accomplish drafting up a Terminal executing script to run such a compare and contrast “check”?
Would I have to learn some BASH or something else?

Would not the Qubes team already have implanted “Stack Canaries” to mitigate that?

I just found out about Stack Canaries

run stuff in disposable qubes

Make a separate topic if you want to discuss something you found. It’s not really related in this case, stack canaries are to used to check memory allocation boundaries, it’s implemented at the OS level. Qubes OS doesn’t make changes to the templates.

What you really want with Qubes OS is to identify

  • what tasks you need to be done
  • how to separate them into qubes
  • identify what is at stake if one qube gets compromised
  • try to run the most sensible tasks in disposable qubes, so if they get compromised this is only temporary

Qubes OS allows risk management, the qubes themselves aren’t very much hardened compared to a regular linux system.

1 Like

No - each qube will only record differences from the base template as
they happen.
At start they will only consume minor amounts of storage - if you keep
the qube online for a long time and, e.g. install software, or download
to /root or some other place outwith /rw, then the storage used may
increase substantially.
When the qube is shut down, that excess storage is deleted.

off topic

Solene bonjour 5 mars 24, nous avons deja echangé…savez vous comment proceder sur la version 4.2 ( qui me semble la plus evoluée depuis 3.2) …;cmment installer sur une template …un ISO ( par exemple : trisquel , que j aime pas mal), jusqu’ a ce jour toute mes tentatives ( avec le suivie d instructions sur youtube …,mais probablement depassées depuis 3.2) ont echouées…si vous savez et si vous trouvez un moment …passez moi une instruction simple ? merci d avance miro , ah ps : comment communiquer sur ce forum( je suis nouveau) en Polonais ?

automatic translation

Solene hello 5 March 24, we have already exchanged…do you know how to proceed on version 4.2 (which seems to me the most evolved since 3.2) …;cmment install on a template…an ISO (for example: trisquel, which I like a lot), to this day all my attempts (with the following of instructions on youtube…, but probably exceeded since 3.2) have failed…if you know and if you find a moment…pass me a simple instruction? Thank you in advance miro, ah ps: how to communicate on this forum (I’m new) in Polish?