Libvirt will replace domain XML when trying to define the new one with
the same name and UUID - this is exactly what we need. This fixes race
condition with other processes (especially Qubes Manager), which can try
to access that libvirt domain object at the same time.
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.
It is used by just started DispVM to notice when restore process
completed. Alternatively it could watch its own domid, but lets do it in
Xen-independent way.
When called from libvirt->libxl, there is libvirt lock taken on that
domain. Because of that, we can't access libvirt domain, so basically
any runtime information. Without that --offline-mode, script waited on
the lock and then was killed by libxl after a timeout - before actually
committing the changes.
Many functions and especially standalone tools takes the lock itself, so
to prevent deadlocks, as a rule execute the tests with lock released.
Also reload qubes.xml before cleanup.
The statement that unlock_db() is always called directly after save() is
no longer true - tests holds the lock all the time, doing multiple saves
in the middle.
This is to make sure that QubesVmCollection state is consistent with
qubes.xml - unfortunately some changes are applied to Qubes*Vm object
only at load time (for example connected_vms collections).
When qfile-dom0-unpacker detects an error, it sends error report to
stdout and terminate (so stdout is closed). That close should be
transferred to the VM process (as EOF on its stdin), which will signal
it to stop sending the data and handle error report.
Also qrexec-client holds the connection until both stdin and
stdout are closed.
So when that EOF is missing, tar2qfile will not detect error report and
still tries to send the data and qrexec-client will hold the
connection while receiving process is long dead.
To prevent that deadlock from happening, close FD in python code, so
qfile-dom0-unpacker will be the last owner of write end of the pipe.
When it closes its stdout, qrexec-client will receive EOF at its stdin.
Test suite now logs to three places:
* syslog
* ${HOME}/qubes-tests.log
* /dev/kmsg (only start and errors; this is handy while debugging Oopses by
correlating them with tests)
