How To Setup A Storage Pool/Storage Driver?

I’m trying to setup an appVM on an external hard drive, inside of a VeraCrypt container.

I’m reading the documentation here:

I don’t have a storage.conf file in etc/qubes.

I can imagine this is because a storage driver was never setup?

How do I set one up?

Unfortunately that linked documentation page is obsolete since R4.0. There’s no longer any such config file. Best to ignore all that stuff completely and start with the qvm-pool manpage in dom0.

Assuming e.g. that you’ve formatted your unlocked VeraCrypt container with a filesystem that supports reflinks (currently Btrfs, or alternatively XFS formatted with -m reflink=1), and it’s already mounted at /mnt/somewhere:

$ qvm-pool -a yournewpoolname file-reflink -o dir_path=/mnt/somewhere

Here’s a more detailed HOWTO that creates a new lvm_thin pool (instead of a new file-reflink pool): Secondary storage | Qubes OS

Veracrypt out of the box supports: Ex2,3,4, FAT, NTFS, exFAT. So I would have to make the vault with no format then re-format with another tool?

…Then follow that guide.

Question:
Let’s imagine Veracrypt is a hidden vault. I open to one outer volume and get one set of files when launching the appVM… close doen the appVM… dismount/remount with into the hidden vault…start the appVM again…

…Will the state change between the outer/inner layer mess up the appVm? Or could it handle such a setup with no problems?

I haven’t used VeraCrypt but that sounds right. The tool would be mkfs.btrfs.

1 Like

Qubes will refuse to start the VM when its volumes are missing, but after remounting, you can start it again. It shouldn’t cause any corruption.

What I’m curious about is state change between the overt vs the hidden inner layer. Having the appVm with the same name, in effect sharing 2 separate sets of files/folders, depending on if the vm is mounted with to the outer or inner layer. Will that break the vm? Is the vm sandboxed… are there dom0 files I need to consider that change from appVm start to start.

Oh I think I might understand your ghost layer thing now. You want to have anti-forensic secondary storage, so that someone analyzing your decrypted dom0 would not be able to tell that the secondary storage even exists? Specifically, if it’s currently not hooked up then the affected VMs should still be able to start but with decoy data from primary storage?

1 Like

I was thinking that I could set it up to either using a Veracrypt 2 layer vault (hidden vault), or better yet, the overt layer is on the primary drive, and the hidden layer is in the Veracrypt drive.

If I use the later approach, wouldn’t I just simlink the appVM root folder from dom0 script, with the Veracrypt hidden layer mounted, rather than setup a separate storage pool for the appVm?

If I want the appVm to load normally, when the external drive is not connected, it would seem I should create a standard appVm, with no storage pool tag?

Then have a script that shuts down the appVm if running, mounts the Veracrypt drive, symlink the root folder, then launches the appVm normally.

My qs for the pros: I can see this working unless there are changes in Dom0 files for that appVm that the symlink cannot reach? Or maybe I need to symlink a Dom0 folder that feeds the appVm?

To access the ghost layer the external drive would need to be mounted and attached to the appVm? Or maybe this is where storage pools come in. How to attach the external drive to the appVm before it starts up?