This is very easy if the file/device is in dom0, so do it to avoid
cryptic startup error (`libvirtError: internal error: libxenlight failed
to create domain`).
FixesQubesOS/qubes-issues#1619
dnf doesn't want to replace packages without --allowerasing (it is
needed to have correct kernel-devel package version). Additionally
really make sure the right version is installed and force u2mfn module
compilation.
There are problems with using sudo in early system startup
(systemd-logind not running yet, pam_systemd timeouts). Since we don't
need full session here, runuser is good enough (even better: faster).
On VM start, old qubesdb-daemon is terminated (if still running). In
practice it happen only at VM startart (shutdown and quickly start
again). But in that case, if the VM was started by root, such operation
would fail.
So when VM is started by root, make sure that qubesdb-daemon will be
running as normal user (the first user in group 'qubes' - there should
be only one).
FixesQubesOS/qubes-issues#1745
Enable e820_host option for VMs with PCI devices (to allow VM kernel to
deal with address space conflicts). But add a property to allow
disabling it.
FixesQubesOS/qubes-issues#2019
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
qrexec-daemon will start new processes for called services, which
include starting new DispVM, starting other required VMs (like backend
GPG VM). Having those processes as root leads to many permissions
problems, like the one linked below. So when VM is started by root, make
sure that qrexec-daemon will be running as normal user (the first user
in group 'qubes' - there should be only one).
QubesOS/qubes-issues#1768
On KDE5 native decoration plugin is used and requires special properties
set (instead of `_QUBES_VMNAME` etc).
Special care needs to be taken when detecting environment, because
environment variables aren't good enough - this script may be running
with cleared environment (through sudo, or from systemd). So check
properties of X11 root window.
QubesOS/qubes-issues#1784
Trim template name to fit full VM name in 31 chars.
At the same time, check if the VM already exists - if so - remove it
first (or error out asking the user to remove it manually - if VM isn't
marked as internal).
Now that VM is created as internal, to skip appmenus creation.
QubesOS/qubes-issues#1910FixesQubesOS/qubes-issues#1655
This behaves better when running multiple VMs. If one need full CPU
power in some VM, it is always possible to increase vCPUs for this
particular VM.
FixesQubesOS/qubes-issues#1891
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
Do not force inheritance of ExtraTestMixin and QubesTestCase. Instead
provide 'qubes.tests.extra.ExtraTestCase' for external tests. This makes
the API less "magic", easier to understand and apply static analysis
tools on it.
QubesOS/qubes-issues#1800
* qubesos/pr/29:
removed unnecessary comparison with True and changed to sysctl instead of remove
Fixed#1930: Delete autostart Symlink when deleting a VM
Display cpu and mem similar to qvm-ls but ordered by cpu time. Also a
one line summary switch which includes the top n cpu consuming vms and
total memory consumption. Intended usage is to e.g. embed in a window
manager widget.
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.
Most of these typos were corrected in the qubes-doc repo as part of a
larger typo fixing sweet, but those changes were reverted when the pages
were regerenated from source.
1. wait=False isn't supportet together with localcmd (explicit, or
implicit via 'input') - qrexec-client refuses such combination
2. When using localcmd, qrexec-client exists as soon as the local command
terminates, not necessary remote. This may not be desired effect when
used with wait=True (the default), so do not use localcmd in such a
case
Found while debugging tests for qubes.USBAttach/qubes.USBDetach - with
wait=True broken, there were a lot of race conditions.
Related to QubesOS/qubes-issues#531
