This is part of fixing qvm-start.
qmemman was moved with minimal touching, mainly module names.
Moved function parsing human-readable sizes from core2. This function is
wrong, because it treats k/M/G as 1024-based, but leave it for now.
Now we generate UUID on domain's instantiation. This is needed, because
we sometimes don't update XML (like in qvm-start).
fixesQubesOS/qubes-issues#1236
Some properties should not be changed by user at will (like UUID). The
solution is to make them write-once, so they will be set when loading
from XML and frozen for the lifespan of the object holding the property.
When desperately needed, users may edit XML by hand.
fixesQubesOS/qubes-issues#1235
This should be done in QubesVm class (property setter). But since we're
going to rewrite both qvm-prefs and QubesVm, settle on smaller change
for now.
QubesOS/qubes-issues#1184
This should be done in QubesVm class (property setter). But since we're
going to rewrite both qvm-prefs and QubesVm, settle on smaller change
for now.
FixesQubesOS/qubes-issues#1273
When restarting VM (starting it just after it was shut down), it may
happen that previous `qubesdb-daemon` instance is still running - if VM
doesn't properly terminate the connection, dom0 part will not terminate
immediately, but at next alive check (every 10s). Such `qubesdb-daemon`,
when terminating, will remove pid file and socket file. In case of new
daemon already running it would be those of the new daemon, making the
whole QubesDB of this VM inaccessible for dom0 (`qubesdb-daemon` is
running, but its socket is removed).
To prevent this race, ensure that previous instance is terminated before
starting the new one.
There is no need to manually removing socket file, because if some stale
socket exists, it will be replaced by the new one when new
`qubesdb-daemon` starts up.
QubesOS/qubes-issues#1241
QubesVM.start() first creates domain as paused, completes its setup
(including starting qubesdb-daemon and creating appropriate entries),
then resumes the domain. So wait for that resume to be sure that
`qubesdb-daemon` is already running and populated.
QubesOS/qubes-issues#1110
QubesWatch._register_watches is called from libvirt event callback,
asynchronously to qvm-start. This means that `qubesdb-daemon` may
not be running or populated yet.
If first QubesDB connection (or watch registration) fails, schedule next
try using timers in libvirt event API (as it is base of QubesWatch
mainloop), instead of some sleep loop. This way other events will be
processed in the meantime.
QubesOS/qubes-issues#1110
