Update documentation on how to shrink private storage in Qubes 4.0

[heinrich-ulbricht]

The problem you're addressing (if any)
How to shrink private storage of AppVMs?

Describe the solution you'd like
I'd like to read documentation on how to do it using the currently existing tools in Qubes 4.0.

Where is the value to a user, and who might that user be?
Useful in the following circumstances:

• increased private storage too much, need to reduce again
• decrease default private storage size after creating a new AppVM

Describe alternatives you've considered
One might create a new AppVM and move data around. Don't want.

Additional context
I over-sized my AppVMs a bit too much leaving me with a near-full disk preventing upgrades to Fedora 30. Doh.

Relevant documentation you've consulted
Google leads to this page apparently documenting how to do it: http://nukama.github.io/doc/ResizeDiskImage/ - starting with:

qvm-prefs -s <vm-name> kernelopts rd.break
qvm-start --no-guid <vm-name>

But it seems outdated with regards to v4.0 (?). E.g. calling qvm-start with --no-guid parameter returns saying it doesn't recognize the parameter --no-guid. Furthermore qrexec doesn't time out even after setting kernelopts rd.break.

Related, non-duplicate issues
#3725 covers this topic as well but seems to aim for simple tooling to do this. I just need an updated documentation.

[heinrich-ulbricht]

Regarding --no-guid - this is a topic here about not breaking this parameter #2412

qvm-start do not accept --no-guid option (was renamed to --no-start-guid) (*)
Generally, lets not break things just for the sake of breaking

Seems to be gone nevertheless.

[brendanhoar]

Did a sudo fstrim -av inside your VM with a large private volume not return the unused storage back to the LVM thin pool?

[esote]

@heinrich-ulbricht If you really want to shrink the size of your AppVM's private pool, use the following command from dom0.

Replace 123M with the new pool size. Replace VMNAME with the name of the Qube (ie personal becoming /dev/qubes_dom0/vm-personal-private). Shut down the VM first.

sudo lvresize --size 123M /dev/qubes_dom0/vm-VMNAME-private

Output (you need to confirm resize of logical volume):

  WARNING: Reducing active logical volume to 123.00 MiB.
  THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce qubes_dom0/vm-VMNAME-private? [y/n]: y
  Size of logical volume qubes_dom0/vm-VMNAME-private changed from 2.00 GiB (512 extents) to 123.00 MiB (31 extents).
  Logical volume qubes_dom0/vm-VMNAME-private successfully resized.

As the command says, it may destroy your data, which is why the Qubes tools do not allow shrinking logical volumes.

With standalone VMs you can also resize /dev/qubes_dom0/vm-VMNAME-root. Use sudo lvs --all to see all pools.

I'm not sure if Qubes needs documentation on this. Since they're thin volumes, over-sizing really only becomes an issue if you actually use all the space allocated, and in that case resizing is dangerous.

[heinrich-ulbricht]

Thank you for your input. On this topic unfortunately I'm an end user and my questions will lack technical background (for the time being). I'm sorry for that.
Let's assume I created a new AppVM with 2 GB private storage (e.g. default configuration). Do I have to differentiate those two cases:
Case 1:

• via Qubes settings I enter 10000 (10 GB) into the private storage edit field and close the dialog
• I fill up private storage with just 1 GB of data
• I proceed as suggested by @brendanhoar or @esote
• expected result: the private storage (as can be seen in the Qubes Settings UI is down to ~1000 (~1 GB)

Case 2 (mine):

• via Qubes settings I enter 10000 (10 GB) into the private storage edit field and close the dialog
• I fill up private storage completely with 10 GB of data
• I remove 9 GB of data from private storage so 9 GB shall be returned to the thin pool (I guess)
• just 1 GB of data is left in my private storage
• I proceed as suggested by @brendanhoar or @esote
• expected result: the private storage (as can be seen in the Qubes Settings UI is down to ~1000 (~1 GB)

Are those expectations correct? And which of the proposed solutions (by @brendanhoar and @esote) is applicable to this case?

Regarding "need to document this": extending the storage is documented here under the title "Resize Disk Image": https://www.qubes-os.org/doc/resize-disk-image/. I expecteded to find at least a hint there how to shrink a volume (which is a form of resizing). Even if it's just a comment like "you don't have to care because of thin volumes" - this would be helpful as well. So I had to dig into old documentation and (apparently) old instructions which such a comment would have helped to avoid.

As for the proposed solutions: I'm happy to try all and report back :)

[brendanhoar]

There's really no point in worrying about the private volume size in the Qubes interface, unless you are concerned about a runaway process in the VM using more space than expected.

The use of a thin ("sparse") backing pool generally mitigates the private volume size. If you invoke discard/trim inside the VM after deletions, the unused space in the logical volume will be returned to the LVM thinpool for use by all VMs.

If it really bothers you that a number is large in the Qubes interface and you have a template-based VM, just create a new VM and move the files there, then delete the original.

Brendan

[andrewdavidwong]

Regarding "need to document this": extending the storage is documented here under the title "Resize Disk Image": https://www.qubes-os.org/doc/resize-disk-image/. I expecteded to find at least a hint there how to shrink a volume (which is a form of resizing). Even if it's just a comment like "you don't have to care because of thin volumes" - this would be helpful as well.

The answer I usually see is: "You can't."

[andrewdavidwong]

If it really bothers you that a number is large in the Qubes interface and you have a template-based VM, just create a new VM and move the files there, then delete the original.

This is what I would do.

[unman]

I've added a section to https://www.qubes-os.org/doc/resize-disk-image/
with appropriate warnings.

@andrewdavidwong @heinrich-ulbricht
If you think that's enough,please close

[andrewdavidwong]

I've added a section to https://www.qubes-os.org/doc/resize-disk-image/
with appropriate warnings.

@andrewdavidwong @heinrich-ulbricht
If you think that's enough,please close

Thanks, @unman.

[heinrich-ulbricht]

Thank you, I find such a hint at the appropriate place very helpful.

@unman One minor note: there now seems to be broken heading markup in the document:

[unman]

@heinrich-ulbricht Thanks for this. Fixed.