When cloning VM, create it in the same pool as the source one.
Previously it always used default pool, which means for example renaming
a VM in non-default pool moved it back to the default one.
FixesQubesOS/qubes-issues#4145FixesQubesOS/qubes-issues#4523
Add note in QubesBase docstring it shouldn't be used directly.
Additionally add base qubesd_call and run_service methods raising
NotImplementedError with helpful message. Lack of qubesd_call in
QubesBase leads to infinite recursion, because one in PropertyHolder
calls itself then.
FixesQubesOS/qubes-issues#4568
The qubesd daemon have no information about clone source - from that
side it looks like a new VM. This means application menu is created as
for a new VM.
To fix this re-initialize menu with --source option as part of the clone
operation. It will copy both list of available applications (if
applicable) and selected applications.
This fixes both qvm-clone case and rename.
FixesQubesOS/qubes-issues#3902FixesQubesOS/qubes-issues#4124
This is especially the case for domain-shutdown event for DispVM - when
handled, DispVM can be already removed. Give the handled VM object even
if actual VM is already removed. For this, avoid VM existence check by
using domains.get_blind() method.
And actually implement domains.get_blind() method - it was present only
in generic collection, but not VMCollection.
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
This restores Qubes R3.2 behavior
Before this patch, the following:
qvm-run -p sys-firewall 'echo -e "\e[0;46mcyan!" >&2' | wc -l
leaks the escape sequences through to the dom0 terminal via stderr,
in this case demonstrated by the ability to change the text color while
it should be fixed to red.
This can also be abused with xterm reporting sequences to cause input
to be sent to the dom0 terminal. This is potentially a security issue.
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 allows to perform actions on objects (VM, storage etc), without
listing them. This is useful when calling VM have minimal permissions
and only selected actions are allowed.
This means that app.domains['some-name'] will not raise KeyError, even
when domain do not exists. But performing actual action (like
vm.start()) will fail in that case.
This way we don't need separate admin.vm.Clone call, which is tricky to
handler properly with policy.
A VM may not have access to all the properties and other metadata, so
add ignore_errors argument, for best-effort approach (copy what is
possible). In any case, failure of cloning VM data fails the whole
operation.
When operation fails, VM is removed.
While at it, allow to specify alternative VM class - this allows
morphing one VM into another (for example AppVM -> StandaloneVM).
Adjust qvm-clone tool and tests accordingly.
QubesOS/qubes-issues#2622
Add qubesd_call(..., payload_stream=...) argument to allow streaming
payload directly from some file/process stdout. This is mainly (only?)
useful for admin.vm.volume.Import, where disk volume raw data is passed
to the service.
It is supported only from dom0, but it's still useful to have, to save
on simultaneous vchan connections (only waiting for MSG_DATA_EXIT_CODE).
This is especially important for Windows VMs, as qrexec-agent there have
pretty low limit on simultaneous connections (about 20).
Make qvm-run use it.
