Even in case of some exception (in which case theoretically it should be
unlocked at qfile-daemon-dvm exit, but the script may wait for
something).
QubesOS/qubes-issues#1636
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
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.
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.