IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Make use of the new helper for showing a standard error message for two
conflicting cli options. This also catches one untranslatable message.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
If specified, this errors if no OS name was detected or manually set.
So --os-variant detect=on,require=on will error if no OS is detected.
name= can be used as a fallback, so test and document this case
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This adds the following --os-variant suboptions
* name=, short-id=
* id=
* detect=on|off
Functionally this does not change behavior, just adds explicit
sub options for behavior we already support
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The --os-variant option naming is pretty crappy and mostly a historical
artifact. Ideally this would be named just `--os` but I'm afraid that
would cause confusion with libvirt's <os> XML
Add --osinfo as an alternate commandline naming. If we ever want to
transition documented use of --os-variant it will help to have the
alternative around for a few releases
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The --xml option allows users to request raw XML edits to virt-install
or virt-xml generated XML. This gives users a bit of a workaround
incase we don't have proper support for some XML property. The --xml
option can gain more features in the future if it makes sense, like
setting XML namespaces for example.
Basic usage is like: virt-install --xml ./@foo=bar ...
Which will change the generated <domain> XML to have
<domain foo='bar' ...
virt-xml works similarly. It can only be combined with --edit currently.
This only works with xpaths rooted against the entire document.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Similar to behavior we have in virt-manager, if the user destroys the
VM during the VM install process, don't invoke the post install
reboot.
https://bugzilla.redhat.com/show_bug.cgi?id=1818089
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* rename kernelupload.py to volumeupload.py and make the entrypoint
more generic
* move all upload invocation to the Installer class
* use it with cloudinit and unattended ISO generation if required
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is a quirk of libvirt that the first <device> is usually a
logical duplicate of the first <serial> device. Adjust virt-xml to
understand this quirk and remove both devices at the same time,
like we already do in virt-manager
https://bugzilla.redhat.com/show_bug.cgi?id=1685541
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This let's us move more of the preserve logic to virtclone.py
and prep more things to share with virt-manager
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* Centralize lots of disk building
* Open code virt-clone specific behavior at the source
* Drop a lot or properties
* Move most testing to test_cli.py
* Generally a ton of cleanup
virt-manager clone wizard has not been converted yet so is totally
broken after this commit
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Cover more cases via the virt-clone CLI testing, than just the
test_cloner.py unit style testing.
Change most of the virt-clone --print-xml testing to also attempt the
clone operation as well via a hidden cli option, to ensure we aren't
testing XML of any bogus operations
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is just a test suite hack from before we had other methods
of specifying cloneable guests. It will be removed soon
We need to tweak some test XML to fix code coverage after
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Add a --iommu option to configure IOMMU parameters as described in
https://libvirt.org/formatdomain.html#elementsIommu
E.g. 'virt-install --iommu model=intel,driver.aw_bits=48,driver.iotlb=on ...'
will generate the following domain XML:
<devices>
<iommu model="intel">
<driver aw_bits="48" iotlb="on"/>
</iommu>
</devices>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Menno Lageman <menno.lageman@oracle.com>
There's valid cases where a VM can be defined with a conflicting MAC
address. Prior to ebd6091cc8e4 and related refactorings we were more
lax here if the conflicting VM wasn't running, but now we are blocking
some valid usage.
Hoist the validation check up to cli.py and add --check mac_in_use=off
to skip the validation. Advertise it like we do for other checks, so
now a collision error will look something like:
The MAC address '22:11:11:11:11:11' is in use by another virtual
machine. (Use --check mac_in_use=off or --check all=off to override)
Reported-by: Pino Toscano <ptoscano@redhat.com>
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Users are fond of using "--tpm /dev/tpm0" to create a TPM device
for their VMs. ppc64 users, however, are experiencing errors because
the default TPM model is 'tpm-tis', which does not work in ppc64, and
they need to specify 'model=tpm-spapr' to work around that.
This patch makes the default TPM model change to 'tpm-spapr' when
running virt-install on a ppc64 host. A new test was added in test_cli.py
to test this new condition. This also keeps the 100% coverage of
the tpm.py file.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
CC: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
CC: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Googling for 'Graphics requested but DISPLAY is not set' shows there's
some confusion about virt-install's behavior in this area. This gives
more output in several related cases about what commands we are
running and the state of the VM
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Currently if the path isn't managed on a remote connection we
treat it as file. Add this simple heuristic to improve the common
case.
https://bugzilla.redhat.com/show_bug.cgi?id=1726202
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Generally this doesn't work with qemu metadata locking nowadays,
and it was never a safe idea to begin with, because disk contents
could be in an inconsistent state.
https://bugzilla.redhat.com/show_bug.cgi?id=1725330
Signed-off-by: Cole Robinson <crobinso@redhat.com>
