There isn’t much discussion about the ephemeral_volatile option that can be enabled with qvm-pool set vm-pool -o ephemeral_volatile=True. When True, this option automatically encrypts DispVM’s volumes with ephemeral keys. I discovered the option in a Github issue:
Is this option safe and stable to enable on the primary vm-pool?
ephemeral_volatile is not specifically about DisposableVMs, and it only encrypts volumes named ‘volatile’ but not ‘root’ or ‘private’! Like other VMs, DisposableVMs have all three of these. They are all deleted on DisposableVM shutdown, but that’s not what volatile means in this context.
(On a technical level, the implementation of a volume’s ephemeral property requires the volume to be neither snap_on_start nor save_on_stop - meaning it has to be a volume that’s freshly created in an empty state on VM startup and discarded on VM shutdown - and ‘volatile’ is the only volume that fits this description.)
There’s a related feature: If you make a VM’s ‘root’ volume read-only (by flipping its rw property to False) then there’s a mechanism inside the VM that will set up a device-mapper based writable layer on top of the read-only volume. Writes to this layer will be redirected to the ‘volatile’ volume. Assuming that ‘volatile’ is ephemeral, ‘root’ will then work as if it was ephemeral too. But unfortunately no such mechanism currently exists for the ‘private’ volume, so it’s not feasible to make that volume read-only as well. If that ever changes (here’s one WIP commit from 2016), we would indeed have all the building blocks for proper anti-forensic DisposableVMs (issue #904).
It should be fine, but it doesn’t see much use so it’s possible that there are some obscure bugs.