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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Tells virt-install to not use UEFI, if it would normally default
to it.
This likely isn't too useful in practice, since all occasions we
default to UEFI require it. But it future proofs opt out in case
we ever start defaulting to UEFI in cases where BIOS still works.
Resolves: https://github.com/virt-manager/virt-manager/issues/692
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The way `--boot uefi` is implemented allows a value to be passed,
but the value is completely ignored. So `--boot uefi=off` or
`--boot uefi=FOOBAR` is treated the same as `--boot uefi`
Lets fix this by making `--boot uefi` and `--boot uefi=on` the same,
`--boot uefi=off` will be implemented later, but any other value
throws an error. This is technically an CLI break but I don't
think it's anything to worry about
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Currently we will only apply the default `--cpu mode=host-passthrough`
config when _no_ `--cpu` config is passed. But this means if a user
configures ex. cpu `<topology>`, we don't set `host-passthrough` and
they get the libvirt/qemu default baseline CPU.
Instead, only skip the default config if the user manually
specified a `mode` or `model` value directly
https://issues.redhat.com/browse/RHEL-65371
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Input XML can have non-existent disk images as long as `--preserve`
is used, or those disks are skipped for any reason. We already
handle that correctly in some cases, but others we fail. This
covers another one.
Resolves: https://github.com/virt-manager/virt-manager/issues/563
Signed-off-by: Cole Robinson <crobinso@redhat.com>
With the libvirt testdriver, we can create+start a directory
pool that points to any arbitrary host path. But this doesn't
match the behavior of the real storage driver, where pool start
will fail if the source directory doesn't exist.
Let's mock this by raising an exception if we are inside the
test suite and we see a special string in the pool XML
Signed-off-by: Cole Robinson <crobinso@redhat.com>
--reflink only works with raw images, since copying anything else
will hit the qemu-img code path in libvirt storage driver.
This can pop up more nowadays since UEFI support is using qcow2 as
well.
Let's only attempt --reflink for raw disk images. It's basically
an optimization anyways
https://bugzilla.redhat.com/show_bug.cgi?id=2256285
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Default to adding tablet+keyboard if graphics and usb are configured.
This saves us from having to duplicate the arch list.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Our logic here is poorly duplicating libvirt's postparse logic.
Notably it will try to add bus=ps2 on non-x86, and misses obscure
cases like parallels.
https://issues.redhat.com/browse/RHEL-66768
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The commit 6baa327d added active_pcr_banks support, but put it under the child
element <tpm>, which is wrong, It should be under sub child element <backend>.
Before:
--tpm model=tpm-tis,backend.type=emulator,backend.version=2.0,\
active_pcr_banks.sha1=on,\
active_pcr_banks.sha256=yes,\
active_pcr_banks.sha384=yes,\
active_pcr_banks.sha512=yes
It results in the following domain xml:
<tpm model='tpm-tis'>
<backend type='emulator' version='2.0'/>
<alias name='tpm0'/>
</tpm>
After:
--tpm model=tpm-tis,backend.type=emulator,backend.version=2.0,\
backend.active_pcr_banks.sha1=on,\
backend.active_pcr_banks.sha256=yes,\
backend.active_pcr_banks.sha384=yes,\
backend.active_pcr_banks.sha512=yes
It results in the following domain xml:
<tpm model='tpm-tis'>
<backend type='emulator' version='2.0'>
<active_pcr_banks>
<sha1/>
<sha256/>
<sha384/>
<sha512/>
</active_pcr_banks>
</backend>
<alias name='tpm0'/>
</tpm>
Signed-off-by: Lin Ma <lma@suse.de>
E.g.
virt-install \
... \
--tpm model=tpm-tis,backend.type=emulator,backend.version=2.0,\
backend.source.type=dir,backend.source.path=/some/dir
It results in the following domain xml:
<backend type="emulator" version="2.0">
<source type="dir" path="/some/dir"/>
</backend>
Signed-off-by: Lin Ma <lma@suse.de>
E.g.
virt-install \
... \
--tpm model=tpm-tis,backend.type=emulator,backend.version=2.0,backend.debug=3
It results in the following domain xml:
<tpm model="tpm-tis">
<backend type="emulator" version="2.0" debug="3"/>
</tpm>
Signed-off-by: Lin Ma <lma@suse.de>
E.g.
virt-install \
... \
--sound model=virtio,streams=4
It results in the following domain xml:
<sound model="virtio" streams="4"/>
Signed-off-by: Lin Ma <lma@suse.de>
E.g.
virt-install \
... \
--sound model=usb,multichannel=yes
It results in the following domain xml:
<sound model="usb" multichannel="yes"/>
Signed-off-by: Lin Ma <lma@suse.de>
E.g.
virt-install \
... \
--disk /tmp/disk0.qcow2,size=16,driver.type=qcow2,blockio.discard_granularity=4096
It results in the following domain xml:
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2' discard='unmap'/>
<source file='/tmp/disk0.qcow2'/>
<target dev='vda' bus='virtio'/>
<blockio discard_granularity="4096"/>
</disk>
Signed-off-by: Lin Ma <lma@suse.de>
- use a single translatable message, instead of splitting the text in
two; it helps translators to have the full context/text
- improve the language a bit
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Drop our hardcoded model lists, and just ask libvirt to fill in
a model for us. Add an entry to the combo box so users can type
in a non-default value if they want one.
Long term libvirt should be providing all this info to us via
domcapabilities
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Currently `--panic default` for aarch64 doesn't even request
a `<panic/>` device due to quirky xmlbuilder behavior. Fix that,
but more generally just leave model empty and let libvirt fill it
in for us.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is a special convenience option for filling in `type=hostdev`
config using the same format of lookup string that can be
passed to `--hostdev`
Fixes: https://github.com/virt-manager/virt-manager/issues/500
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This just covers the common PCI case with these new options
source.address.type=
source.address.domain=
source.address.bus=
source.address.slot=
source.address.function=
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Fix no longer valid URL fragments, wrap at 80th column, remove dots that
follow only a few links.
Signed-off-by: Grzegorz Szymaszek <gszymaszek@short.pl>
This is essentially what it has always behaved as, but making it
explicit in the code will now trigger the extra warnings when
detect=on is also used.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Using `detect=on,name=OSNAME` is good for CI safety, incase
a new distro tree has a regression with detection, or if testing
against a new distro that osinfo-db doesn't know about.
But virt-install should still try to inform the user that detection
failed, and suggest filing a bug if the user expected it to work.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The require= behavior should be AUTO for this case, but the
way we were previously initializing variables made this OFF.
I don't think this was intentional. We should have changed
this when we started defaulting to `detect=on`
Signed-off-by: Cole Robinson <crobinso@redhat.com>
It's kinda hard to follow the logic here. cli require= can only be
on|off or unset, but we use an internal 'auto' value which seems
like it can come from the cli.
Try to clean it up with enum like values.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
has_install_phase is an ambiguous name for its intended purpose.
Really this is so API users have a way of knowing if the VM `install`
process requires 2 XML phases or not. Make that naming explicit
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This basically reverts this commit from virt-manager 4.0.0
```
commit 825ec644b8
Author: Cole Robinson <crobinso@redhat.com>
Date: Tue Mar 1 10:32:01 2022 -0500
installer: Do not force reboot with --cloud-init
Resolves: https://github.com/virt-manager/virt-manager/issues/189
```
After that commit, using `--cloud-init` or `--unattended` would
basically imply `--noreboot`
For some usage of `--cloud-init`, like in the initial report, this
makes sense to do. virt-install will drop you into the cloud image,
you mess without, run `poweroff`, and are surprised when virt-install
reboots the VM. I agreed, and made the change
But changing this was a bad idea.
cloud-init and unattended VMs have 2 XML phases. First XML is booting
off temporary media (the generated cloudinit iso), second XML is the
permanent boot config (booting off disk). We need to force the VM
to fully poweroff, so that the second XML config takes effect. We
make that happen with `<on_reboot>destroy</on_reboot>`, which tells
libvirt/qemu to poweroff the VM when it receives a guest reboot
notification. virt-install then defaults to restarting the VM when
it detects shutdown, to manually replicate the VM requested reboot,
but still get the second XML config to take effect.
The perennial problem with this is that, from outside the VM, we
don't know if the user inside the VM requested `poweroff` or `reboot`.
virt-install emulates the reboot behavior, and provides `--noreboot`
to override it. It's still confusing if a user puts a `poweroff`
command at the end of an anaconda kickstart file, and sees the VM
reboot, but it's been that way forever.
Except with that commit above, we flipped it for --cloud-init and
--unattended. Now, users who do `poweroff` are getting expected
behavior, but users who request `reboot` are not.
We could go further and add a `--yesreboot` option or similar. But
for consistency sake I think we should just revert that behavior,
and tell users to use --noreboot like usual.
Resolves: https://github.com/virt-manager/virt-manager/issues/497
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This wires up the guest.convert_to_vnc function to command line,
and documents it.
There's one suboption `qemu-vdagent=on|off`, defaulting to `off`
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is the beginnings of support for a `virt-xml --convert-to-vnc`
option. Take an existing VM, strip out most of the previous graphics
config, and add VNC graphics.
We try to convert over some of the shared graphic bits, like listen
and port settings, if they were previously specified.
If spice GL was enabled, we convert to egl-headless config
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Wire up guest.convert_to_q35 to the CLI. We add one suboptions,
`num_pcie_root_ports=X`, matching the pre-existing
`--controller num_pcie_root_ports=X` option
Nothing fancy here. See man page docs for details
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This function converts a PC/i400FX XML config to Q35. Mostly
this is deleting any plain PCI addresses and controllers, adding
pcie-root-ports, convert IDE -> SATA, and let libvirt fill in
the rest.
This the implementation piece. CLI additions come later
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We can make `--xml` fit the common xml cli option paradigm, which
less us drop a whole bunch of special handling in virt-xml
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Adjust cli.py `run_parser` and similar functions to take the
parservalue directly, rather than passing in the whole `options`
structure.
This makes it easier to reason about what the virt-xml action
functions are actually working with.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This adds an Action class which is a container for (most) of the
data we need to perform a virt-xml operation. Basically an instance
of the class represents a pairing like
--edit 1 --disk path=/foo or
--add-device --network wibble,model=virtio
etc
This is a functional no-op, but it moves the code closer to
an architecture that will allow us to perform multiple actions
with a single virt-xml command.
While doing this, we centralize most of the cli validation that is
scattered around, since it's now easier to do it in one place.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Move the validation functions out from amongst the functional XML
editing code, and into their own section. We will be adding more
code alongside in future patches.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
