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
Leave the 'proper' fix of making this package noarch commented
out for now, to allow this to be merged.
Comments as per the parallel submit to qubes-artwork.
This is QA tool for checking if names of the events are the same when
firing and handling. The core intentionaly has no provision for
registering the events, so another means are needed for checking them.
This allows the user to start VM based on "old" system (from R3.x) in
R4.0. For example after restoring from backup, or migration. This also
makes upgrade instruction much easier - no need complex recovery
instruction if one upgrade dom0 before upgrading all the templates.
QubesOS/qubes-issues#1812
- introduce 'firewall-changed' event
- add reload_firewall_for_vm stub function
Should that function be private, called only from appropriate event
handlers?
QubesOS/qubes-issues#1815
It may be (and by default is) path relative to VM directory.
This code will be gone in the final version, after merging firewall
configuration into qubes.xml. But for now have something testable.
It is much less error-prone way. Previous approach didn't worked because
VMs weren't added here at 'domain-init'/'domain-loaded' event. And even
after adding such handlers it wasn't working because of
QubesOS/qubes-issues#1816.
It may be a little slower, but since it isn't used so often
(starting/stopping VM and reloading firewall), shouldn't be a problem.
