Disposable implementation
Note: The content below applies to Qubes R3.2.
DisposableVM image preparation
DisposableVM is not started like other VMs, by executing equivalent of
xl create
- it would be too slow. Instead, DisposableVM are started
by restore from a savefile.
Preparing a savefile is done by
/usr/lib/qubes/qubes_prepare_saved_domain.sh
script. It takes two
mandatory arguments, appvm name (APPVM) and the savefile name, and
optional path to “prerun” script. The script executes the following
steps:
APPVM is started by
qvm-start
xenstore key
/local/domain/appvm_domain_id/qubes_save_request
is createdif prerun script was specified, copy it to
qubes_save_script
xenstore keywait for the
qubes_used_mem
key to appear(in APPVM) APPVM boots normally, up to the point in
/etc/init.d/qubes_core
script when the presence ofqubes_save_request
key is tested. If it exists, then(in APPVM) if exists, prerun script is retrieved from the respective xenstore key and executed. This preloads filesystem cache with useful applications, so that they will start faster.
(in APPVM) the amount of used memory is stored to
qubes_used_mem
xenstore key(in APPVM) busy-waiting for
qubes_restore_complete
xenstore key to appear
when
qubes_used_mem
key appears, the domain memory is reduced to this amount, to make the savefile smaller.APPVM private image is detached
the domain is saved via
xl save
the COW file volatile.img (cow for root fs and swap) is packed to
saved_cows.tar
archive
The qubes_prepare_saved_domain.sh
script is lowlevel. It is usually
called by qvm-create-default-dvm
script, that takes care of creating
a special AppVM (named template_name-dvm) to be passed to
qubes_prepare_saved_domain.sh
, as well as copying the savefile to
/dev/shm (the latter action is not done if the
/var/lib/qubes/dvmdata/dont_use_shm
file exists).
Restoring a DisposableVM from the savefile
Normally, disposable VM is created when qubes rpc request with target
$dispvm is received. Then, as a part of rpc connection setup, the
qfile-daemon-dvm
program is executed; it executes
/usr/lib/qubes/qubes_restore
program. It is crucial that this
program executes quickly, to make DisposableVM creation overhead
bearable for the user. Its main steps are:
modify the savefile so that the VM name, VM UUID, MAC address and IP address are unique
restore the COW files from the
saved_cows.tar
create the
/var/run/qubes/fast_block_attach
file, whose presence tells the/etc/xen/scripts/block
script to bypass some redundant checks and execute as fast as possible.execute
xl restore
in order to restore a domain.create the same xenstore keys as normally created when AppVM boots (e.g.
qubes_ip
)create the
qubes_restore_complete
xenstore key. This allows the boot process in DisposableVM to continue.
The actual passing of files between AppVM and a DisposableVM is implemented via qubes rpc.
Validating the DisposableVM savefile
DisposableVM savefile contains references to template rootfs and to COW files. The COW files are restored before each DisposableVM start, so they cannot change. On the other hand, if templateVM is started, the template rootfs will change, and it may not be coherent with the COW files.
Therefore, the check for template rootfs modification time being older
than DisposableVM savefile modification time is required. It is done in
qfilexchgd
daemon, just before restoring DisposableVM. If necessary,
an attempt is made to recreate the DisposableVM savefile, using the last
template used (or default template, if run for the first time) and the
default prerun script, residing at
/var/lib/qubes/vm-templates/templatename/dispvm_prerun.sh
.
Unfortunately, the prerun script takes a lot of time to execute -
therefore, after template rootfs modification, the next DisposableVM
creation can be longer by about 2.5 minutes.