On Sun, Mar 12, 2017 at 5:52 AM, Jazz Kittens <[email protected]> wrote: > Ideally I'd like to have: > > 1) volatile.img write out to /dev/shm > 2) private.img write out to /dev/shm > > In the case of 1 the linked discussion below states: > >> /var/lib/qubes/appvms/fedora-18-x64-dvm/dvm.conf): > >> 'script:file:/var/lib/qubes/appvms/fedora-18-x64-dvm/volatile.img,xvdc,w', > > https://groups.google.com/forum/#!topic/qubes-devel/QwL5PjqPs-4 > > I have attempted this on an appvm. However, something reverts the config > file back to its default state after it has been run. Any ideas? > > In the case of '2', ideally I'd like the same kind of setup as the rootfs > image: a read only image that writes out COW data to another image. This is > so I can boot the appvm with said image in rw mode, make configuration > changes to /home, and reboot it into ro mode - where any further changes are > written to a cow image in /dev/shm instead. > > I'm a little unsure about where /home changes are made in the template, or > if the configuration i've described is possible. > > To make life easier for answers: > > A) What is reverting changes in the appvm.conf file, and can this behavior > be changed? > B) Can appvm specific private.img files be configured to work in a similar > fashion as volatile.img files i.e. RO and COW, and is it possible that they > can be changed/configured on the fly? > C) Where are changes to /home in the template vms written to? > > Crazy request, but it's something I'm willing to work upon.
The appvm.conf file is not actually what's passed to xen, it's just there for convenience to view for debugging. A copy of the same contents is piped through directly. If you wish to start an AppVM with custom config, use qvm-start --custom-config=/tmp/some-appvm.conf As for /dev/shm, you probably don't want that as it'll put large memory pressure on dom0. If the reason you are trying to put things there is actually to resist local forensics (by only storing vm contents in memory), then a better solution would be to encrypt the copy-on-write deltas with an ephemeral single-boot key which is forgotten on shutdown. This has been on my to-do list for some time, but still haven't gotten around to it. It should be fairly straightforward to achieve with another dm-crypt loop dev, but I have not actually done it myself yet. See also https://github.com/QubesOS/qubes-issues/issues/904 -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/CABQWM_BDdbE3gLYLY%2BfN3ESkLAezasmniFJkKMpNtpk-Adiabg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
