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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Enable dependabot for the "main" branch, letting it scan for outdated
GitHub Actions used in workflows on a weekly base.
Signed-off-by: Pino Toscano <ptoscano@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>
Libosinfo seems to generate Fedora tree URLs using the "https", not
"http", scheme now; which breaks CI. Update the expected outputs
accordingly.
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>
