When calling _register_watches() multiple times for dom0 (by passing
None or since 7e9c816b by passing the corresponding libvirt domain) the
check was missing if there is already a QubesDB in _qdb. Therefore a new
QubesDB was created and the old one is destroyed by the GC. As a
consequence the watch_fd is closed but the libvirt event handle for this
fd is still registered. So when libvirt calls poll() it returns
immediately POLLNVAL with the closed fd. This is not caught in libvirt
and the callback is called as if an event happened. _qdb_handler() now
calls read_watch() on the new fd for dom0 and thereby hangs the thread.
This leads (at leads) to qubes-manager to miss VM status updates and
block device events.
FixesQubesOS/qubes-issues#2178
- for netvm it doesn't make sense, but instead of removing it (which
surely will break some code), make it always False
- when settings VM connections, uses_default_netvm is already loaded
- handle it properly during backup restore (really use default netvm,
istead of assuming it's the same as during backup)
Libvirt reports dom0 as "Domain-0". Which is incompatible with how Qubes
and libxl toolstack names it ("dom0"). So handle this as a special case.
Otherwise reconnection retries leaks event object every iteration.
FixesQubesOS/qubes-issues#860
Thanks @alex-mazzariol for help with debugging!
Make sure that even compromised frontend will be cut of (possibly
sensitive - like a webcam) device. On the other hand, if backend domain
is already compromised, it may already compromise frontend domain too,
so none of them would be better to call detach to.
QubesOS/qubes-issues#531
This requires having at least 1GB free on /tmp, but it is fair
assumption - it's tmpfs in dom0 and while performing the backup most of
the VMs aren't running, so shouldn't be a problem. Anyway it is always
possible to set TMPDIR variable or pass --tmpdir cmdline option.
Using tmpfs based temporary directory should speedup the backup.
QubesOS/qubes-issues#1652
qhost.measure_cpu_usage expects the qvm_collection as parameter. Also
the number of vcpus of dom0 seems to be 0, leading to a div by 0. A more
complete fix would probably involve e.g. a new num_cores property which
would contain number of vcpu for vhosts and number of actual cores for
dom0.
For now this is a partial solution.
It should be created at VM creation time (or template changes commit).
But for example for HVM templates created before implementing
QubesOS/qubes-issues#1573, there would be no such image. So create it
when needed, just before VM startup
FixesQubesOS/qubes-issues#1602
We still can't support running HVM template and its VMs simultaneously
(easily), but still, have root-cow.img handled for HVM template, to
allow qvm-revert-template-changes.
FixesQubesOS/qubes-issues#1573
- QubesVmStorage provides now a default get_config_params() method which should
be enough for all possible Storage implementations.
- When writing a custom Storage implementation, one has just to reimplement the
following methods:
* root_dev_config()
* private_dev_config()
* volatile_dev_config()
- QubesVmStorage provides a default implementation of other_dev_config(),
because it can be shared by all storage implementations
* qubesos/pr/12:
Fix circular deps workaround in Pool.vmdir_path()
Move device names from XenStorage to QubesVmStorage
Provide method format_disk_dev() to all storages
Move the vmdir logic from XenPool to Pool
The method XenStorage._format_disk_dev() generates the xml config for a device.
It is not specific to the Xen file storage implementation. It can and must be
reused by other storage implementations
If SendWorker queue is full, check if that thread is still alive.
Otherwise it would deadlock on putting an entry to that queue.
This also requires that SendWorker must ensure that the main thread
isn't currently waiting for queue space when it fails. We can do this by
simply removing an entry from a queue - so on the next iteration
SendWorker would be already dead and main thread would notice it.
Getting an entry from queue in such (error) situation is harmless,
because other checks will notice it's an error condition.
FixesQubesOS/qubes-issues#1359
For a long time Qubes backup did not include symlinked files, which
apparently is quite common practice for users with multiple disks (for
example HDD + SSD). It is covered in documentation
(https://www.qubes-os.org/doc/secondary-storage/), but better solution
would be to simply include symlinked files.
Restore of such files would (of course) not preserve the symlinks -
normal files will be restored instead. But that's fine. If the user want
to move the data to another location, he/she can do that and restore the
symlink.
The only possible breakage from this change is having a copy (instead of
symlink) to a VM icon. But storing that symlink in a backup was broken
for some time (because of --xform usage) and it is handled during
restore, so not a real problem.
This doesn't cover all the problems with symlinked VM images - the other
one is qvm-block behaviour, which would treat such images as non-system
disks, so easily detachable (which would break VM operation). But that's
another story.
FixesQubesOS/qubes-issues#1384
In most cases it would be some leftover after failed restore, or even
the reason why the user is restoring a VM in the first place. Move it to
nearby directory, but do not remove - backup tool should _never_ remove
any data.
When the pre-existing directory would not be moved, restore utility
(`shutil.move`) would place the data inside of that directory, with
additional directory level (for example `/var/lib/qubes/appvms/work/work`),
which would be wrong and would later fail on `vm.verify_files`. And more
importantly - such VM would not work.
FixesQubesOS/qubes-issues#1386
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
