Create / convert Btrfs pools as their own subvolumes

[tasket]

The problem you're addressing (if any)

Installing Qubes on Btrfs leaves the system with a monolithic default subvolume, encompassing all of dom0 and domU storage. This creates a hurdle for users wishing to exploit Btrfs features beyond reflink copies, such as subvolume snapshots (which can themselves be required in preparation for various procedures such as backups via btrfs-send or Wyng); isolating domU pools from rest of filesystem can be important.

The solution you'd like

Create a separate Btrfs subvolume at or just after system installation on Btrfs. Also perhaps offer to convert referenced directory to subvolume when the user is defining a new pool on Btrfs.

The value to a user and who that user might be

Avoiding after-the-fact moves of existing data:

This allows the user to pursue their Btrfs storage agenda without the uncertainly of moving possibly 100GB+ of data into a new subvolume and then moving the subvol into the pool's path. (Not time/resource consuming but its still a manual operation that may put some people off.)

Related:

• Switch default pool from LVM to BTRFS-Reflink #6476
• Qubes GUI integration tasket/wyng-util-qubes#36

Completion criteria checklist

No response

[alimirjamali]

I once suggested that even private and root pools should be separate pools from each other (and from /). Since user might prefer different backup schedule for applications and data:

#9424

And I still that the more we go forward, the more it makes sense (specially for backup and snapshots).

[marmarek]

Just to clarify - is it about a single subvolume for all VMs (basically /var/lib/qubes), or separate subvolume for every VM? @tasket

[bi0shacker001]

I would advocate for separate subvolumes for each VM. This would also allow for snapshotting and reverting individual Qubes by tracking subvolumes, an incredibly useful feature of pretty much every other virt infrastructure, and an in-os feature of various OSes which run on BTRFS, including OpenSUSE. The ability to rollback Qubes is incredibly useful if you plan to do something potentially destructive.

[marmarek]

. This would also allow for snapshotting and reverting individual Qubes by tracking subvolumes, an incredibly useful feature of pretty much every other virt infrastructure

You can do that already, see qvm-volume info and qvm-volume revert.

[bi0shacker001]

If I'm not mistaken, this doesn't allow for a version history

[marmarek]

It does keep last 2 versions by default. But if you want, you can increase this number (see revisions_to_keep volume property).

[alimirjamali]

It does keep last 2 versions by default. But if you want, you can increase this number (see revisions_to_keep volume property).

I believe what @bi0shacker001 refers to is a named snapshot. Something like (end-2024, after-successful-upgrade, before-major-upgrade, etc.). Something which would stay untouched regardless of number of times a qube is restarted.

p.s.: While the above is easily doable with BTRFS snapshots, it should not be something which "requires" btrfs. It is possible to implement it via other means.

[bi0shacker001]

It does keep last 2 versions by default. But if you want, you can increase this number (see revisions_to_keep volume property).

I believe what @bi0shacker001 refers to is a named snapshot. Something like (end-2024, after-successful-upgrade, before-major-upgrade, etc.). Something which would stay untouched regardless of number of times a qube is restarted.

p.s.: While the above is easily doable with BTRFS snapshots, it should not be something which "requires" btrfs. It is possible to implement it via other means.

This is much more in line with my intent, though I wasn't aware that you could keep multiple revisions of the vms. The problem with that system is, by the time you realize you need to roll back, it might be too late. Sometimes issues take longer to manifest. So unless I'm gonna keep 50 revisions of each of my VMs, that doesn't help with my specific concern, though it's an amazing little bit of functionality that should probably be added to the gui. Particularly for Windows HVMs, the ability to roll back after a broken driver install would have saved me so many times recently

[marmarek]

FWIW, thanks to CoW, cloning VMs is pretty cheap. You can have a clone called for example "windows-known-good" and use it only as a named snapshot (if you want to revert a broken VM to it, remove the broken one and clone "windows-known-good" to it). Not ideal, but does cover some cases.