The Python version (and pylint) are new enough finally.
Adjust QubesVM.run* functions for now.
Python 3.8 brings also AsyncMock() which makes tests slightly less ugly.
- nopat - added when PAT in Linux+Xen was buggy, no longer the case for a
long time.
- iommu=soft swiotlb=8192 - necessary to limit required memory on PV with
PCI devices; since we use HVM now (with proper IOMMU translation), this
is no longer needed. Furthermore, it will free some memory in sys-* vms.
Instead of unintuitive Value Error now we have dedicated QubesLabelNotFoundError.
Goal: to make qvm-prefs be less strange when one mixes up gray and grey again.
Deduplicate entries when iterating over TestVMsCollection values. Some
tests add given VM multiple times, to have it available under different
kind of keys (name, uuid etc) - similar to the real VMsCollection.
* origin/pr/254:
vm: allow StandaloneVM to be a DVM template
vm: do not allow setting template_for_dispvms=False if there are any DispVMs
vm: move DVM template specific code into separate mixin
* devel20200705:
tests: skip gnome-terminal on xfce template flavor
tests: fix FD leak in qrexec test
tests: switch default LVM pool to qubes_dom0/vm-pool
backup: fix error handler for scrypt errors
Adjust code for possibly coroutine Volume.export() and Volume.export_end()
storage: add Volume.export_end() function
backup: add support for calling a function after backing up a file/volume
backup: call volume.export() just before actually extracting it
vm/dispvm: place all volumes in the same pool as DispVM's template
tests: extend TestPool storage driver to make create_on_disk working
storage: pass a copy of volume_config to pool.init_volume
tests: cleanup properly in wait_on_fail decorator
Make all volume's pool controlled by DisposableVM Template. This
specifically makes DispVM's volatile volume to be placed directly in the
same pool as its template.
FixesQubesOS/qubes-issues#5933
Add dummy TestVolume with empty create() method. Other core code
requires also TestPool.get_volume implemented, so add that too (naive
version remembering instances returned from TestPool.init_volume).
XSA-320 / CVE-2020-0543 affects Ivy Bridge and later platforms, but a
fix (microcode update) won't be available for Ivy Bridge. Disable
affected instruction (do not announce it in CPUID - complying software
should not use it then).
* origin/pr/330:
gui: fixes from Marek's comments
gui: improvements of feature keyboard layout checks
tests: adapt tests for keyboard-layout
gui: drop legacy qubes-keyboard support
This commit adds a test case for the QubesVM class's is_fully_usable
method. The verified scenarios are as follows:
* The VM has qrexec enabled, and the qrexec service has been
successfully started.
(The VM becomes "fully usable" in this case.)
* The VM has qrexec enabled, and the qrexec service has failed to start
(Error handling case; the VM is *not* fully usable.)
* The VM does *not* have qrexec enabled.
(The VM becomes "fully usable" in this case.)
* origin/pr/303:
Update tests after adding /connected-ips
Also reload /connected-ips on firewall change / domain spawn
Also store /connected-ips6 for machines that have IPv6 addresses
Don't try to write to qubesdb of an offline VM
Maintain a list of connected machine IPs in qubesdb
Extension objects are singletons and normally do not require any special
cleanup. But in case of tests, we try to remove all the qubes objects
between tests and the cache in usb extension makes it hard.
Add a 'qubes-close' event that extensions can handle to remove extra
references stored in extension objects themselves.
Only first 4 disks can be emulated as IDE disks by QEMU. Specifically,
CDROM must be one of those first 4 disks, otherwise it will be
ignored. This is especially important if one wants to boot the VM from
that CDROM.
Since xvdd normally is a kernel-related volume (boot image, modules) it
makes perfect sense to re-use it for CDROM. It is either set for kernel
volume (in which case, VM should boot from it and not the CDROM), or
(possibly bootable) CDROM.
This needs to be done in two places:
- BlockExtension for dynamic attach
- libvirt xen.xml - for before-boot attach
In theory the latter would be enough, but it would be quite confusing
that device will get different options depending on when it's attached
(in addition to whether the kernel is set - introduced here).
This all also means, xvdd not always is a "system disk". Adjust listing
connected disks accordingly.
- allow TestQubesDB to be populated with initial data
- support list() method
- allow to register pre-created VM instance (useful for AdminVM, which
don't accept setting qid)
