qubes-doc/developer/services/disposablevm-implementation.rst
Marek Marczykowski-Górecki b93b3c571e
Convert to RST
2024-05-21 20:59:46 +02:00

120 lines
4.2 KiB
ReStructuredText
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

=========================
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:
1. APPVM is started by ``qvm-start``
2. xenstore key ``/local/domain/appvm_domain_id/qubes_save_request`` is
created
3. if prerun script was specified, copy it to ``qubes_save_script``
xenstore key
4. wait for the ``qubes_used_mem`` key to appear
5. (in APPVM) APPVM boots normally, up to the point in
``/etc/init.d/qubes_core`` script when the presence of
``qubes_save_request`` key is tested. If it exists, then
1. (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.
2. (in APPVM) the amount of used memory is stored to
``qubes_used_mem`` xenstore key
3. (in APPVM) busy-waiting for ``qubes_restore_complete`` xenstore
key to appear
6. when ``qubes_used_mem`` key appears, the domain memory is reduced to
this amount, to make the savefile smaller.
7. APPVM private image is detached
8. the domain is saved via ``xl save``
9. 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:
1. modify the savefile so that the VM name, VM UUID, MAC address and IP
address are unique
2. restore the COW files from the ``saved_cows.tar``
3. 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.
4. execute ``xl restore`` in order to restore a domain.
5. create the same xenstore keys as normally created when AppVM boots
(e.g. ``qubes_ip``)
6. 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.