Store volatile.img in separate location

[marmarek]

Community Dev: @v6ak
PoC: https://gist.github.com/v6ak/d5d49375d59cfae8e455
Discussion: https://groups.google.com/forum/#!topic/qubes-users/X0BBZ-kfix0

---

@v6ak https://groups.google.com/d/msgid/qubes-users/1f975e13-45bb-4146-b651-a59b07560a29%40googlegroups.com

I am trying to move my volatile.img files to another location. There are
two (three) reasons for it:

1. Some additional secrecy; the filesystem is encrypted by a password from
   /dev/random, so no one can read the volatile.img files after reboot.
2. Performance (+ reduces wear when used with SSD): The filesystem for is
   tuned for performance at the cost of consistency when computer is forcibly
   turned off. This is undesirable for main FS, but OK for a dedicated
   filesystem for this purpose.

I have prepared such a temporary filesystem to be mounted under /largetmp.
(Well, I might change it just to /tmp.) There is nothing I have problem
with, so I'll share the details below.

Now, I would like to move all the volatile imgs there. I have grepped for
volatile.img in Qubes sources. The easiest (though somewhat hacky) way to
do this seems to be adding the following line before truncate command to
/usr/lib/qubes/prepare-volatile-image.sh:
ln -s "/largetmp/volatile-$(printf %s "$FILENAME" | base64 -w0 | sed
's#/#:#g')" "$FILENAME"

(...)

Linked message contains also PoC

Related to #904

[andrewdavidwong]

@v6ak: Just checking in. Did you happen to continue to do any work on this after your last update? Any further progress or findings you're willing to share with us would be much appreciated!

[v6ak]

It seems that it is up-to-date. As a quick hack for 3.0 (and probably also for 3.1, though it might require minor changes), it seems to work perfectly.

A clean solution, would, however, require some code refactoring. As far as I remember, the current code for 3.0 (and probably also for 3.1) assumes that volatile.img is located in the VM's directory. I am not sure where are those assumptions made (it might be few places and is might be many different places as well), so I've decided to use the hacky symlink approach, which partially preserver the assumption of same directory for volatile.img.

And I am totally unsure what changes are brought by 3.2/4.0 branches. Either there might be some refactoring that makes this change easier or there might be something that breaks my approach and makes it even harder to refactor the code.

[andrewdavidwong]

@v6ak, would you be willing to package your contribution according to our new package contribution procedure?

[v6ak]

Well, first of all, this modification works in 3.2 and older. In 4.0, LVM is used. AFAIU, there is no equivalent of volatile.img. Instead, there are COW shapshots that need to be stored in the same LVM VG. I have checked if I can add a volatile PV and add it to the VG, but this is a dead end, as LVM does not let me to control which PV is used for what data. So, I could have ended with volatile data stored on non-volatile PV (this beats the purpose) or non-volatile data on volatile PV (=> data loss and logical volume corruption). Well, maybe even the current design can allow something like this in a limited way. We can just focus on swap and maybe /tmp, ignoring writes to /. But I would have to investigate it further.

[marmarek]

Each VM still have volatile volume. By default it is used for swap only, but if root volume in template-based VM is read-only, then dm-snapshot within VM is used to for CoW layer (same as it was in R3.2).
By default root volume is exposed read-write, and CoW is done by LVM in dom0.

You can set rw volume property using qvm-volume tool. And you can also create separate storage pool for volatile volumes and use it either for individual VM (qvm-create --pool volatile=...) or set as global default (qubes-prefs default_pool_volatile ...).