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
Depends on the method introduced in QubesOS/qubes-core-admin#307.
Adding the get_mem() method using the same CurrentState admin
method also fixes the bug with qvm-ls not showing memory, see
QubesOS/qubes-issues#5166.
The method will ensure the parameters are properly handled as actual
separate arguments, regardless of shell special characters in them.
For now implement this with shlex.quote, later dedicated qrexec service
could be used.
QubesOS/qubes-issues#4850
When calling a service in DispVM, the connection is established only
after session is ready (if required for given service). qrexec-client by
default use 5s here, which is too low depending on hardware. Use
'qrexec_timeout' property here for DispVM case.
FixesQubesOS/qubes-issues#3012
vm.get_power_state() have specifically documented 'NA' state for cases
when it's unable to get VM's power state. Use this when qrexec policy
forbid checking it.
Reported by @pietrushnic
FixesQubesOS/qubes-issues#3179
First, TemplateVM is not used anymore (see previous commit). Second,
don't harcode on client side that "only TemplateVM can be a template for
any VM" (which actually isn't true: AppVM can be a template for DispVM).
Very few calls at client side really needs VM class name. So, even in
non-blind mode use just QubesVM class, to avoid strange cases depending
on blind mode being enabled or not. Then, have VM class name in 'klass'
property. If known at object creation time, cache it, otherwise query
qubesd at first access.
This is a wrapper to use `$dispvm` target of qrexec call, just like any
other service call in qubesadmin module - using vm.run_service().
When running in dom0, qrexec-client-vm is not available, so DispVM needs
to be created "manually", using appropriate Admin API call
(admin.vm.CreateDisposable).
QubesOS/qubes-issues#2974
Since we use qubes.VMShell service now and send requested command on its
stdin, we need to terminate that shell after requested command -
otherwise the service will not terminate automatically waiting for
further input (next commands).
