Registering event implementation in libvirt and then not calling it is
harmful, because libvirt expects it working. Known drawbacks:
- keep-alives are advertised as supported but not really sent (cause
dropping connections)
- connections are not closed (sockets remains open, effectively leaking
file descriptors)
So call libvirt.virEventRegisterDefaultImpl only when it will be really
used (libvirt.virEventRunDefaultImpl called), which means calling it in
QubesWatch. Registering events implementation have effect only on new
libvirt connections, so start a new one for QubesWatch.
FixesQubesOS/qubes-issues#1380
There are some circular dependencies (TemplateVM.appvms,
NetVM.connected_vms, and probably more), which prevents garbage
collector from cleaning them.
FixesQubesOS/qubes-issues#1380
The only directory to cleanup is cls.tmpdir. So make it simple, without
class property cleanup_paths, which for some reason didn't wasn't
emptied in tearDownClass.
This process may be running as root in case of default NetVM. But do not
kill it forcibly (through sudo or so), because it may also be stale
pid file. After all, QubesDB should automatically terminate when its VM
is terminated, so this code is already some error handling.
FixesQubesOS/qubes-issues#1331
* qubesos/pr/7:
Don't send screen layout to the VM if we haven't received it from xrandr because this breaks proper initial screen layout set by gui-agent FixesQubesOS/qubes-issues#1305QubesOS/qubes-issues#998
If /etc/localtime in dom0 is a hardlink to zoneinfo file (instead of
symlink) and more than one zoneinfo file is hardlinked to this inode,
appVMs will get invalid timezone, e.g. "Europe/Warsaw\x0aPoland".
Reported by @yaqu, fix provided by @yaqu
FixesQubesOS/qubes-issues#1315
If running as normal user, chown will fail. This isn't a problem,
because the file is probably already owned by the correct user. The
whole point about this chown is to give access to the file for normal
user, so if the write succeeded, it isn't needed.
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
