Best Way To Resize Dom0 Pool?

I have a 500GB drive. The Qubes showing in Qubes Manager take up less than 50GB. I’m trying to make a Veracrypt vault in Dom0. It tells me have 13GB free space.

…something doesn’t compute.

I’ve ran:

sudo dnf clean all
sudo journalctl --vacuum-time=ls

Yet not much changed in available disk space.

I can assume 2 things:

All the Qubes I’ve made and deleted while testing somehow haven’t been cleared from memory?

Or the Dom0 pool size parameter is set too small?

…Is there another command I need to run to reclaim that space?

I got this command on another related post:
sudo lvextend -l +100%FREE /dev/mapper/qubes_dom0-pool00

Now before I mess something up running commands I can only assume do what I think they do, how’s the best way to get access to the other 400+gb that I should have on this drive?

Did you try KDE-partitionmanager in dom0? Yesterday I resized it from 20 to 100GB, while still the amount of free (unallocated) space on the disk is the same (which is expected, of course since VMs occupy not that much space, so free space is not needed for extending). If VeraCrypt insists on unallocated space, then I guess 13GB is all you have.
In that I case, I’d backup Qubes, make a new clean install, during install I’d clam less than actual 487GB space, and then restore the backup.

The partition manager is showing 464gb partion of 500. I don’t think I can change the partition.

Reinstalling: Well,$$%^ is there no other way to free up space?
Do you get to the bottom of what’s causing the space not to be reclaimed?

Just for some background on the current setup…
If veracrypt was installed in a newly created vm based on a template (ex. fedora-34, debian-11), thin volume provisionng of private storage should increase as necessary.
ref: Resize disk image | Qubes OS
Resizing the system max. size of the template settings on which the vm is based is also possible.
If this is off the mark maybe the output of pvs, lvs, vgs for the specific volume might help. (with any specific details altered to protect your disk naming and structure layout)

[quote=“1of7, post:4, topic:8192, full:true”]…
If veracrypt was installed in a newly created vm based on a template (ex. fedora-34, debian-11), thin volume provisionng of private storage should increase as necessary.

Absolutely. That’s why I wrote “if VeraCrypt insists on unallocated space”. Otherwise, no worry, until VeraCrypt’s VM size is theoretically < (500GB - ~50GB (other VMs) - 20 (or 30GB for dom0)).

The key question is where VeraCrypt should/could go… If in dom0, then you have to and can resize it. If in Vm, no additional steps needed. If in free space, then new installation.

Maybe this is of a help:

Whether veracrypt is placed in a vm or dom0 it will still be within the LV and LUKS(2).

Creating ‘hidden’ volumes for ‘secret qubes’ would require creating other volumes. Not sure what direction the OP was going.

If a dedicated ‘vault’ vm works for split-gpg/ssh why not use the vm approach.

Just remember that the default LVM pool setup in R4.1 is different than R4.0.


Under R4.0, one VG, one thin pool, dom0 LVs are simply siblings with VM LVs.

Under R4.1, one VG, two thin pools, dom0 LVs in one thin pool (smaller), VM LVs in a different thin pool (larger).

Also, under R4.1 the thin pools are not set up to consume 99-100% of the VG, but less.

The thin pools are, however, set to autoextend their sizes into the unused space in the VG as needed. This allows them to grow separately.

The purpose of this change was to ensure the likeliest case of VM LVs growing too large and leading to thin pool failure will not impact the ability to reboot qubes into a working dom0 environment since that is in a separate thin pool.

However, storing large amounts of data directly in the dom0 filesystem could lead to the dom0 thin pool exceeding the VG and leaving you with an unbootable system.

My recommendation is not to store large amounts of data in the dom0 filesystem.