When netvm and firewallvm is shut down, netvm handling code will
try to revoke firewallvm access to external IP. But if netvm shutdown
happens in the meantime, xenstore will throw ENOENT error.
In such case show an error to the user (via tray notification, not
dialog box!) and leave the VM in "transient" state. The user can wait
some more time for VM startup, check what VM is doing, or kill it
manually.
Some programs (like KDE system settings) makes /etc/localtime hardlink
instead of symlink. Handle this case. Hopefully there will be less and
less such applications...
Alway start stubdom guid, then if guiagent_installed set - start the
target one and when connects, kill stubdom one. This allow the user to
see startup messages so prevent the impression of hang VM.
Note 1: this doesn't work when VM disables SVGA output (just after
windows boot splash screen).
Note 2: gui-daemon sometimes hangs after receiving SIGTERM (libvchan_wait
during libvchan_close). This looks to be stubdom gui agent problem.
This is somehow related to #757, but only first (easier) step. Actual
change of QubesAdminVm base class requires somehow more changes, for
example qvm-ls needs to know how to display this type of VM (none of
template, appvm, netvm).
Make this first step change now, because starting with R2Beta3 dom0 will
be stored in qubes.xml (for new backups purposes) so this rename would
be complicated later.
Using class method allow the users (Qubes Manager at least) to check
for compatibility without having any particular VM instance - useful
while creating the VM.
Any HVM (which isn't already template-based) can be a template for
another HVM. For now do not allow simultaneous run of template and its
VM (this assumption simplify the implementation, as no root-cow.img is
needed).
HVM can set some xenstore entries (in qubes-tools/ subtree) to pass
informations about installed tools to dom0. qubes.NotifyTools service
triggers update of VM properties (like qrexec_installed).
This way, after installation of Qubes Windows Tools, the user doesn't need
to change any VM settings to use the tools.
If not marked as installed, start it in background - waiting for
possible Qubes Tools installation. If that happens, make it possible to
tell the dom0 about that fact.
