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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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>
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>
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>
When Spice graphics is used QEMU creates a Spice server and communicates
with Spice client using multiple channels. These channels are used by
the spice devices as well. Without the Spice graphics defined there is
no use for the other devices. In addition libvirt will report error for
such configuration.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Add adaptations for loongarch with the following features:
Default video Support
UEFI prefer
Usb tablet and usb keyboard
rng and memballoon
sound device
Usb controller
Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
This won't make any difference on x86, where either SATA or IDE
is used depending on the machine type, but on other architectures
we want virtio-scsi for a reasonable chance that the guest OS
will recognize the disk.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Most existing disk images expect UEFI; those that don't, require
either using direct kernel boot or manually providing a firmware
image, both of which imply user intervention.
Using UEFI by default means that at least images belonging to
the first group, of which more are going to pop up as the
ecosystem matures further, can work out of the box.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
When shim in the guest sees unpopulated EFI NVRAM, like when
we create a new UEFI VM, it invokes fallback.efi to populate
initial NVRAM boot entries. When the guest also has a TPM device,
shim will do a one time VM reset. This reset throws off the
reboot detection that is central to virt-install's install
process.
The main install case that this will usually be relevant is
the combo of UEFI and --cloud-init. The latter usually implies
use of a distro cloud image, which will be using shim, and the
--cloud-init process requires a multi stage install compared
to just a plain import install.
For that case, we disable the default TPM device for the first
boot.
https://bugzilla.redhat.com/show_bug.cgi?id=2133525
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Commit f107e39989 ("Switch to more traditional logging structure",
2019-06-17) replaced "logging.exception" with "log.exception", effectively
shifting the argument lists 4 characters to the left. The second and
further lines of multiline invocations were not accordingly unindented,
however, which ended up setting a suboptimal precedent as well. Unindent
those lines now.
Reported-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Just to be sure, this patch implements the second approach (described in
the previous patch) as well.
Note that there is precedent for suppressing "guest_lookup" exceptions:
refer to the "Error determining machine list" branch from commit
ae7ebc220b ("details: Properly limit machine type list by guests
arch/type", 2013-09-01).
(
In fact, that branch gets activated when opening the details window for a
domain that uses a non-default emulator; the "virt-manager --debug" log
contains:
> ERROR (details:613) Error determining machine list
> Traceback (most recent call last):
> File "virtManager/details/details.py", line 605, in _init_details
> capsinfo = caps.guest_lookup(
> File "virtinst/capabilities.py", line 319, in guest_lookup
> raise ValueError(msg)
> ValueError: Host does not support domain type kvm with machine
> 'pc-q35-8.1' for virtualization type 'hvm' with architecture 'x86_64'
)
Fixes: #539
Fixes: 05fcc7410e ("virtinst: fix caching of domain capabilities", 2022-07-27)
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
When I try to open the details window for a domain that does not use the
system default emulator, I get the following exception:
> Traceback (most recent call last):
> File "virtManager/vmwindow.py", line 40, in get_instance
> cls._instances[key] = vmmVMWindow(vm)
> File "virtManager/vmwindow.py", line 83, in __init__
> self._details = vmmDetails(self.vm, self.builder, self.topwin,
> File "virtManager/details/details.py", line 389, in __init__
> self._init_details()
> File "virtManager/details/details.py", line 807, in _init_details
> vmmAddHardware.build_video_combo(self.vm, video_dev)
> File "virtManager/addhardware.py", line 816, in build_video_combo
> default = DeviceVideo.default_model(vm.xmlobj)
> File "virtinst/devices/video.py", line 47, in default_model
> if (guest.lookup_domcaps().supports_video_virtio() and
> File "virtinst/guest.py", line 656, in lookup_domcaps
> if not self._domcaps or not _compare(self._domcaps):
> File "virtinst/guest.py", line 646, in _compare
> if self.os.machine and not _compare_machine(domcaps):
> File "virtinst/guest.py", line 633, in _compare_machine
> capsinfo = self.lookup_capsinfo()
> File "virtinst/guest.py", line 674, in lookup_capsinfo
> self._capsinfo = self.conn.caps.guest_lookup(
> File "virtinst/capabilities.py", line 319, in guest_lookup
> raise ValueError(msg)
> ValueError: Host does not support domain type kvm with machine
> 'pc-q35-8.1' for virtualization type 'hvm' with architecture 'x86_64'
This is a regression; according to git-bisect, it was introduced in commit
05fcc7410e ("virtinst: fix caching of domain capabilities", 2022-07-27).
"lookup_capsinfo" (and "guest_lookup" called by it) are unsuitable for
machine type alias checking (or for anything else) if the domain uses an
emulator that differs from the system default emulator. The information
returned by virConnectGetCapabilities() pertains to the system default
emulator. Thus, when using a non-default emulator, we should either not
call "lookup_capsinfo" for machine type alias checking, *or* we should
suppress the exception, and pretend that the alias check was a mismatch.
It turns out that we can avoid the "lookup_capsinfo" call (and thereby the
exception) in practice if we just delay the call until after the direct
(non-alias) comparison.
Fixes: #539
Fixes: 05fcc7410e ("virtinst: fix caching of domain capabilities", 2022-07-27)
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
It allows to set the thread pool size to optimize spawning worker threads
for the default event loop in real time environment. For example:
--iothreads defaultiothread.thread_pool_min=8,\
defaultiothread.thread_pool_max=16
Signed-off-by: Lin Ma <lma@suse.com>
These two optional attributes allow setting lower and upper boundary for
number of worker threads for given IOThread. For example:
--iothreads iothreads=2,\
iothreadids.iothread0.id=1,\
iothreadids.iothread1.id=2,\
iothreadids.iothread1.thread_pool_min=8,\
iothreadids.iothread1.thread_pool_max=16
Signed-off-by: Lin Ma <lma@suse.com>
The domain capabilities XML always contains the canonical machine name.
When the selected machine type for a guest is an alias, the check
comparing it to the domain capabilities machine will always fail. This
prevents the domain capabilities result from being cached.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
* Check it for test:/// URI too
* Move the whole logic into osdict.requires_firmware_efi
* Wrap it all in an exception handler the final API breaks us
* Add some coverage exclusions since this is currently untestable
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Windows 11 only supports EFI for installation, legacy BIOS is
discontinued as an option for new installs, unless you switch into
the console and run various regedit hacks in the installer.
This is not something we expect users to do, so osinfo-db will
report:
<firmware arch="x86_64" type="efi"/>
<firmware arch="x86_64" type="bios" supported="false"/>
for Windows 11.
When seeing 'bios' with supported=false, we need to prefer EFI
firmware no matter what.
For other OS we should stil prefer BIOS, because EFI blocks the usage of
internal qcow2 snapshots until some libvirt work is done to use the new
QMP snapshot commands.
Note this relies on a new API osinfo_os_get_complete_firmware_list
just added to libosinfo in version 1.10, so for most existing OS
distros this will be dormant functionality until they rebase to
latest libosinfo APIs.
The Windows 11 entry for osinfo-db will be the first that exposes
the metadata indicating lack of BIOS support.
Related: https://github.com/virt-manager/virt-manager/issues/310
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This is a virt-xml option to refresh a VM to use the latest machine
type version for the machine type it's currently using. Ex:
pseries-2.11 -> pseries
pc-q35-5.0 -> q35
This is useful for when qemu deprecates and removes the machine type
out from under you, or to pick up bug fixes.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We enable default graphics for all of ppc64, but really the only
thing we have ever tested is pseries, so make that clear.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This reverts commit 20d3bf9484.
Indeed graphics does work on aarch64, but for example, fedora
server aarch64 installs don't output any graphical output and only
put data on the serial console. So we would need to be more specific
about how we enable this if we make the change.
qemu 6.1, fairly new when we added this option, has an unfortunate
bug with >= 15 root ports, so we choose 14 instead of our original 16
https://gitlab.com/qemu-project/qemu/-/issues/641
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Libvirt defaults to PCIe for arm32/aarch64 and riscv -M virt too.
Rename q35_pcie_root_ports to num_pcie_root_ports and extend the
logic to those archs too
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Add extra PCIe root ports to enable q35 device hotplug to work out
of the box. A typical modern linux guest has 7-8 PCI devices added
by default, so this gives plenty of wiggle room.
The smart thing to do would be to count the attached PCI devices
and add 4-5 extra, but that takes more work and isn't trivial.
The number can be overridden on the cli with:
--controller q35_pcie_root_ports=X
Use =0 to go back to the old behavior.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Historically over time it's been more likely that an issue is reported
for osinfo-db missing the usb-tablet annotation. So for example we
always enable it for the default 'generic' case. We also want to
enable it for osinfo's 'unknown' case too.
Rather than add another check for that, let's just drop the osinfo
checking entirely. Some very old OS don't support usb-tablet, but
specifying it for those cases doesn't cause issues AFAIK, and users
can override it with `--input none` if they want.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
<os firmware='efi'> is the libvirt official way to do what we
historically implement with `--boot uefi`, and UEFI setup in
virt-manager.
Let's prefer libvirt's official method if the support is advertised
in domcapabilities.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This replaces the pattern:
Guest.set_uefi_path(Guest.get_uefi_path())
With a single entrypoint
Guest.enable_uefi()
to immediately change the guest config to use UEFI, using our
default logic.
This will make it easier to change that logic in the future, like
using <os firmware='efi'> instead of hardcoded paths
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Both these windows versions are now longer supported, and UEFI isn't
the default, so I don't think this hack is much needed anymore
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The bare metal world is moving to a situation where UEFI is going to be
the only supported firmware and there will be a strong expectation for
TPM and SecureBoot support.
With this in mind, if we're enabling UEFI on a VM, it makes sense to
also provide a TPM alongside it.
Since this requires swtpm to be installed we can't do this
unconditionally. The forthcoming libvirt release expands the domain
capabilities to report whether TPMs are supported, so we check that.
The user can disable the default TPM by requesting --tpm none
https://github.com/virt-manager/virt-manager/issues/310
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The sync_vcpus_topology method will sometimes set the self.vcpus prop,
but other times leave it unset. This is confusing an unhelpful
behaviour. Both callers have logic to set the self.vcpus prop
to a default value of sync_vcpus_topology failed to do so. It makes
more sense to just pass this default value in.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This includes support for the following suboptions:
* name (<shmem name=X>)
* role (<shmem role=X>)
* model.type (<shmem><model type=X/>)
* size (<shmem><size>X)
* size.unit (<shmem><size unit=X/>)
* server.path (<shmem><server path=X/>)
* msi.vectors (<shmem><msi vectors=X/>)
* msi.ioeventfd (<shmem><msi ioeventfd=X/>)
