Both tools issue a large number of Admin API calls and greatly benefit
from a cache filled with a single per-vm Admin API call
(admin.vm.property.GetAll). In case of qvm-ls, this also saves multiple
admin.vm.CurrentState calls (power state is given in the admin.vm.List
response too).
QubesOS/qubes-issues#3293
Power state changes are signaled with events too, so it is possible to
cache it and update/invalidate cache with events.
Additionally, admin.vm.List returns a power state, so the cache can be
populated early. This in particular greatly improves qvm-ls performance -
eliminate admin.vm.CurrentState call at all.
QubesOS/qubes-issues#3293
Qrexec itself does not support loopback calls. Since a call into dom0
is a common case for GUIVM (which may be dom0) to do, add a convenient
handling inside vm.run_service() function.
FixesQubesOS/qubes-issues#5140
When caching is enabled, reduce number of calls by getting all the
properties at once. If the call is not available (for example because of
the policy), fallback to getting individual values.
QubesOS/qubes-issues#5415
Reduce Admin API calls by caching returned values. The cache is not
enabled by default, because it could result in stale values being
returned. It can be enabled by setting 'cache_enabled' to True on
Qubes() object. This is safe in two cases:
- the application don't care about changed values - like a short-lived
process that retrieve values once (for example qvm-ls)
- the application listen for events and invalidate cache when property
is changed
For the second case, invalidating the cache on appropriate event
(property-set:*, property-reset:*) is done before calling other event
handlers. This is because the event may try to access the property value
(not necessary from the event arguments), so we need to be sure it will
see the new value.
FixesQubesOS/qubes-issues#5415
When qubesd returns an name of VM or other object, as part of another
call (reading a property, listing devices etc), it's safe to assume that
object exists. Do not try to list it, which could be prevented by qrexec
policy. This means a VM object would be returned (for example in
vm.netvm property), which potentially could not be listed through
app.domains collection. This may lead to some corner cases, but
generally should ease handling of restricted policy.
This does not affect practical information the management VM have access
too, as those names are already returned. It's just client side python
wrapper that didn't allowed to access them.
QubesOS/qubes-issues#5099
* origin/pr/118:
qvm-start-daemon: adjust pacat pid file path
qvm-start-daemon: check if layout is parsed
qvm-start-daemon: allow multiple options in keyboard layout
qvm-start-daemon: improve parsing args for setting keyboard layout
qvm-start-daemon: set keyboard-layout only for the first set layout
gui: set keyboard layout when starting daemon
daemon: start it for dom0 unconditionnaly
qvm-start-daemon: ensure separate task between GUI/AUDIO
qvm-start-daemon: allow starting only if service enabled
Fix and improvements from Marek's comments
Change qvm-start-gui to qvm-start-daemon for handling audio too
Support for AudioVM
* origin/pr/136:
Added tests for cloning VMs with persistent devices
Remove Python 2 workarounds
Cloning a vm now clones persistent PCI device assignments
Rules will be reset to a single 'accept' line, which is something
that the GUI tools like. It's an easy way to get out of CLI firewall
modifications if someone wants to go back to using GUI for them.
fixesQubesOS/qubes-issues#4710
