If desired netvm presence is different than during savefile creation(*),
defer setting the netvm until new DispVM is running - otherwise kernel
there will not notice the change and will either have (not working)
'eth0' when it shouldn't, or will not have it while it should.
Additionally set dispvm.uses_default_netvm = False, so GUI tools will
display actual netvm value.
(*) Actually compare to netvm set for dispvm template (`TEMPLATE-dvm`
VM), which can be different if user just changed that but not
regenerated dispvm savefile yet.
Fixesqubesos/qubes-issues#985
Related to qubesos/qubes-issues#862
Luckily it is used as argument to commands with does not allow any
harmful arguments (virsh set(max)mem). Also usage in arithmetic
expression does not allow any harmful usage in this place.
This script is connected directly to calling process, so any output here
will disrupt qrexec service data. For example in case of qubes.OpenInVM
this will be prepended to modified file while sending it back to the
source VM - in case of no modification, it will override that file in
the source VM...
This allows to specify tight network isolation for a VM, and finally
close one remaining way for leaking traffic around TorVM. Now when VM is
connected to for example TorVM, its DispVMs will be also connected
there.
The new property can be set to:
- default (uses_default_dispvm_netvm=True) - use the same NetVM/ProxyVM as the
calling VM itself - including none it that's the case
- None - DispVMs will be network-isolated
- some NetVM/ProxyVM - will be used, even if calling VM is network-isolated
Closesqubesos/qubes-issues#862
Apparently it is much faster. Especially during savefile preparation -
tar reads the whole file, while bsdtar gets file map and reads only used
regions.
It have nothing to do with xenstore, so change the name to not mislead.
Also get rid of unused "xid" parameter - we should use XID as little as
possible, because it is not a simple task to keep it current.
Move DispVM creation to qfile-daemon-dvm/QubesDisposableVm from
qubes-restore. As actual restore is handled by libvirt, we don't get
much from separate qubes-restore process.
This code still needs some improvements, especially on performance.
Do not let hotplug script inherit lock FD - if it starts some long
running process (like xenstore-watch), it will hold the lock and block other scripts.
Apparently it doesn't work with some kernels - saved domain still needs
original memory amount to restore successfully. This happens at least on
3.12.14 kernel.
Because qfile-daemon-dvm always requests 400MB from qmemman, this change
should harm anyone - in any case DispVM needs 400MB free memory to
start.
Note that "xl mem-set" line is still there, which makes savefile somehow
smaller (so faster restore).
Opening a DispVM when the TemplateVM is running forces savefile
regeneration. Checking real root.img modification time (taking into
account root-cow.img) is tricky, so display a warning instead.
Now gui-agent supports reconnect to guid, so start it early to have Xorg
running in the VM.
This is still not done - for example it tries to run some commands via
(not running yet) qrexec.
It would work twice, but no more.
Also guard explicitely against buffer overflow, since once that
code actually works, sizeof(buf)-buflen will be interpreted as
large positive, and allow overwriting the stack.
