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
qubes.VMShell service, used by qvm-run, expects the command on the first
input line. Previously, when --localcmd was used, the command wasn't
written anywhere and the local command was connected directly to
qubes.VMShell service. And the first line of its output was interpreted
as a command.
Fix this by starting the local command separately, after sending the
command to qubes.VMShell service.
While at it, unify handling shell command and service calls in the process.
vm.run_service(..., localcmd= ) isn't that useful in general case,
because for qubes.VMShell the caller first need to send the command
before starting local process. Since the qvm-run tool needs to implement
manual starting localcmd anyway, don't use localcmd= run_service's
argument at all to unify calling methods.
There is slight behavior change: previously localcmd was started only
after establishing service connection (for example only if qrexec policy
allows), now it is started in all the cases.
FixesQubesOS/qubes-issues#4040
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
By definition StandaloneVM is not linked to the template. Creating one
from a template is a clone operation. It's already possible using
qvm-clone tool, but it's logical to do that using qvm-create tool too.
This was the case in R3.2 too.
While adding this special case, skip cloning private volume, to preserve
behaviour of TemplateBaseVMs which do not inherit private volume either.
FixesQubesOS/qubes-issues#3793
Port 5a39e777089d8bde6d0a620830a898c1cf3dd924 ("events: add support for
wildcard event handlers") from qubes-core-admin:
Support registering handlers for more flexible wildcard events: not only
'*', but also 'something*'. This allows to register handlers for
'property-set:*' and such.
If file to be imported is larger than the default root volume, resize
the volume first. It might be also a good idea to shrink it when needed,
but currently the backend refuse it.
FixesQubesOS/qubes-issues#3422
Add an explicit method for forcing emulated VGA output. Previously it
was possible only by removing `gui` feature (setting it to false had a
different effect), or enabling debug mode.
Using lack of a feature as a third state was a bad idea.
QubesOS/qubes-issues#3585
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.
Right now Admin API backend will refuse to shrink volume anyway, but
we're planning to relax this restriction. Make sure the client side
(qvm-volume tool here, GUI VM settings already have this in place) will
employ appropriate safety check.
QubesOS/qubes-issues#3725
If needs to be extended - do it before import. If needs to be reduced -
after. This way, if data import fails for any reason, previous data
won't be destroyed (truncated).
Also, convert error on shrinking volume to a warning, as it doesn't break
the template (just leave it with bigger disk than needed). Currently all
storage pool implementations refuse to shrink a volume (but it may
change in the future).
QubesOS/qubes-issues#3169
'qvm-run --dispvm' cannot easily make a separate qubes.WaitForSession
call. Instead, if --gui is active, pass the new WaitForSession argument
to qubes.VMShell, which will do the equivalent.
The unit tests have been copied (in slightly adapted form) from commit
a620f02e2aFixesQubesOS/qubes-issues#3012ClosesQubesOS/qubes-core-admin-client#49
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
In core-admin matching collections are real dicts, so clone this API
behaviour here too. Specific changes:
- iteration yields keys, not values
- implement values and items methods
Additionally fix keys method, it was broken on python2 (list have no
copy method).
* qubesos/pr/44:
Fix style else-return
tests: update qvm-template-process and qvm-remove tests
Add --force to manpage.
Avoid cloning installed_by_rpm
Print vm list before prompt
Use --force instead of --yes
Toggle installed_by_rpm in template tool
Fix error message grammar
Add --yes option and confirm prompt.
Make use of better security of Qubes 4.x by using HVM by default. If
some VMs are incompatible with it (like MirageOS based), user can always
switch it to PV manually later.
