Path to root or private volume: configurable or dynamically generated?

Say I wanted to temporarily replace a vm’s lvm private volume with another volume in VM configuration under qubes, run the vm, exit the vm, and then restore the configuration, is this possible with changes to python code?

So, effectively: temporarily use a private volume that doesn’t match the VM name. Is there a way to do this without modifying the storage.py or lvm.py code?

B

add new pool
qvm-clone -P new_pool vm1 vmnew_pool

I might wrong, but why would you do that ?

I’m brainstorming ways to ensure that all changes to app vm or disposable vm volumes are not written as plaintext, (this is entirely separate from the blanket luks encryption of the entire system).

Lvm has a peculiar requirement that snapshots all originate from data on the same VG. there’s a way to make it work but it plays with some quite finicky PV/VG settings that might make the system broken on an unplanned reboot.

For app VMs and disposable VMs, I want to use the lower-level dm snapshot from lvm to storage outside of the VG, which allows me to put the snapshot (of, say, root or private) on separately encrypted storage, whether ephemeral or vault-like.

E.g. With root I’d have a plain text readonly origin (from a template root snapshot on lvm) and an encrypted ephemeral change volume elsewhere that is disposed of in vm shut down.

B

this could be lead to general discussion since i can’t provide an answer but i’m still curious,
from my understanding you try to install templatevm in qubes_dom0 vg and create appvm / disp vm in lets say qubes_dom1 vg right ?

Potentially or have the AppVM snapshot of root be outside of any VG (that is, outside of LVM entirely), while still using then template’s root as snapshot origin.

interesting, i could have a test but what is the point of this ?

Primarily to support ephemerally encrypted VMs or vault-like encrypted VMs with different keys and unlock/lock times than the primary disk/pool luks layer.

One may, at a client site, not want to unlock the data of another client in an environment that may be competitive or even hostile, where an unlocked/lost laptop could be forensically scanned for fragments of competitors data from snapshots.

There are ways to store additional template/appVM pairs on other pools (perhaps they are on external storage) but that’s clunky and requires unlocking/mounting them to keep the templates up to date.

Anyway back to my original question: is the path to the VM’s volumes stored as an editable value anywhere or is it always algorithmically derived based on the name of the VM and assigned pool?

B