transport.close() (necessary to detach reader from the loop) will close
the FD. In case of stdin, it will prevent another call to this waiting
function. Use dup(2) to register cloned FD, which is safe to close
without side effects.
Since qubesd-side clone_vm function is gone, it doesn't make sense to
test it. For some time already this tested only if manual step-by-step
clone implemented _in the test itself_ was done correctly.
Actual cloning is part of qubes-core-admin-client and is tested there.
- 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.
Make an exception in vm.start() actually interrupt the test. The
asyncio.wait() returns list of completed tasks, where exception may be
stored - but is not raised directly. Change to asyncio.gather() that will
propagate the exception by default.
As a side effect, avoid deprecated direct coroutine passing to
asyncio.wait(). This functionality in asyncio.gather() is not
deprecated.
Add an API for VMs to announce support for non-service features. This is
very similar to supported-service.* features, but applies to non-service
features. This may be also used for announcing support for features that
do not use qvm-features framework itself - for example some VM kernel
features, installed drivers, packages etc.
QubesOS/qubes-issues#6030
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
* test-fixes20200806:
tests/extra: add vm.run(..., gui=) argument
tests: collect detailed diagnostics on failure
tests: workaround a race in qrexec test
tests: fix audio recording test
tests: make qvm-sync-clock test more reliable
Help debugging test failures by collecting detailed information on
failure. It will be logger to the standard logger, which will end up
either on stderr or in journalctl.
qrexec-client-vm may return earlier than it's child process (it exits
right away, without waiting for its child). Add a small wait before
reading exit code from a file.
* paranoid-restore:
tests: paranoid backup restore
Add policy for paranoid mode backup restore
Add an extension preventing starting a VM while it's being restored
Add support for 'tag-created-vm-with' feature
To calculate frequency it needs to use samples per second (44100), not
samples pre recording lenght. This caused shorter recordings to not fit
into the margin.
Policy allows a VM with 'backup-restore-mgmt' tag to create VMs, and
then manage VMs with 'backup-restore-in-progress' tag (which is added by
AdminExtension, based on 'tag-created-vm-with' feature).
VM with 'backup-restore-mgmt' tag can also call qubes.RestoreById
service to a VM with 'backup-restore-storage' tag. This service allows
to retrieve backup archive.
QubesOS/qubes-issues#5310
Compare the time with the "current" time retrieved from ClockVM just
before comparing, not with the test start time. This should work even if
the test machine is quite slow (test taking more than 30s).
Do not allow starting a VM while the restoring management VM has still
control over it. Specifically, that restoring VM will not be able to
start just restored VM.
QubesOS/qubes-issues#5310
When a VM with 'tag-created-vm-with' feature set creates a VM (using
Admin API), that VM will get all the tags listed in the feature.
Multiple tags can be separated with spaces.
This will be useful to tag VMs created during paranoid mode backup
restore.
QubesOS/qubes-issues#5310
As discussed in the PR, sync code will not be interrupted when run from
async code as long as Qubes OS doesn't run dedicated threads for async
& sync code. So there's simply no issue to be expected and thus no special
caution required.
Added:
post_volume_create & post_volume_import as requested by Marek
Removed:
post_ctor as this wasn't really useful anyway, but required a lot of
sync code. Without it, some refactoring & potential async improvements
became possible.
This reverts commit 287a4a0429.
As Marek correctly pointed out, sync functions cannot be run async against one another even if run inside an async function
(the python interpreter will remain active until the next yield and that's at the end of the sync func / inside the async function).
--> So there's no need for a lock.
I still cannot protect against assumptions made by sync code authors about blocking the Qubes OS main loop. Those will be broken.
Moreover the code of this commit was botched anyway.
