[FOSDEM][CFP] Virtualization & IaaS Devroom
by Piotr Kliczewski
We are excited to announce that the call for proposals is now open for the
Virtualization & IaaS devroom at the upcoming FOSDEM 2022, to be hosted
virtually on February 5th 2022.
This year will mark FOSDEM’s 22nd anniversary as one of the longest-running
free and open source software developer events, attracting thousands of
developers and users from all over the world. Due to Covid-19, FOSDEM will
be held virtually this year on February 5th & 6th, 2022.
About the Devroom
The Virtualization & IaaS devroom will feature session topics such as open
source hypervisors and virtual machine managers such as Xen Project, KVM,
bhyve, and VirtualBox, and Infrastructure-as-a-Service projects such as
KubeVirt, Apache CloudStack, Foreman, OpenStack, oVirt, QEMU and OpenNebula.
This devroom will host presentations that focus on topics of shared
interest, such as KVM; libvirt; shared storage; virtualized networking;
cloud security; clustering and high availability; interfacing with multiple
hypervisors; hyperconverged deployments; and scaling across hundreds or
thousands of servers.
Presentations in this devroom will be aimed at users or developers working
on these platforms who are looking to collaborate and improve shared
infrastructure or solve common problems. We seek topics that encourage
dialog between projects and continued work post-FOSDEM.
Important Dates
Submission deadline: 20th of December
Acceptance notifications: 25th of December
Final schedule announcement: 31st of December
Recorded presentations upload deadline: 15th of January
Devroom: 6th February 2022
Submit Your Proposal
All submissions must be made via the Pentabarf event planning site[1]. If
you have not used Pentabarf before, you will need to create an account. If
you submitted proposals for FOSDEM in previous years, you can use your
existing account.
After creating the account, select Create Event to start the submission
process. Make sure to select Virtualization and IaaS devroom from the Track
list. Please fill out all the required fields, and provide a meaningful
abstract and description of your proposed session.
Submission Guidelines
We expect more proposals than we can possibly accept, so it is vitally
important that you submit your proposal on or before the deadline. Late
submissions are unlikely to be considered.
All presentation slots are 30 minutes, with 20 minutes planned for
presentations, and 10 minutes for Q&A.
All presentations will need to be pre-recorded and put into our system at
least a couple of weeks before the event.
The presentations should be uploaded by 15th of January and made available
under Creative
Commons licenses. In the Submission notes field, please indicate that you
agree that your presentation will be licensed under the CC-By-SA-4.0 or
CC-By-4.0 license and that you agree to have your presentation recorded.
For example:
"If my presentation is accepted for FOSDEM, I hereby agree to license all
recordings, slides, and other associated materials under the Creative
Commons Attribution Share-Alike 4.0 International License. Sincerely,
<NAME>."
In the Submission notes field, please also confirm that if your talk is
accepted, you will be able to attend the virtual FOSDEM event for the Q&A.
We will not consider proposals from prospective speakers who are unsure
whether they will be able to attend the FOSDEM virtual event.
If you are experiencing problems with Pentabarf, the proposal submission
interface, or have other questions, you can email our devroom mailing
list[2] and we will try to help you.
Code of Conduct
Following the release of the updated code of conduct for FOSDEM, we'd like
to remind all speakers and attendees that all of the presentations and
discussions in our devroom are held under the guidelines set in the CoC and
we expect attendees, speakers, and volunteers to follow the CoC at all
times.
If you submit a proposal and it is accepted, you will be required to
confirm that you accept the FOSDEM CoC. If you have any questions about the
CoC or wish to have one of the devroom organizers review your presentation
slides or any other content for CoC compliance, please email us and we will
do our best to assist you.
Call for Volunteers
We are also looking for volunteers to help run the devroom. We need
assistance with helping speakers to record the presentation as well as
helping with streaming and chat moderation for the devroom. Please contact
devroom mailing list [2] for more information.
Questions?
If you have any questions about this devroom, please send your questions to
our devroom mailing list. You can also subscribe to the list to receive
updates about important dates, session announcements, and to connect with
other attendees.
See you all at FOSDEM!
[1] https://penta.fosdem.org/submission/FOSDEM22
[2] iaas-virt-devroom at lists.fosdem.org
3 years
[ANN] oVirt Node 4.4.9.3 Async update
by Sandro Bonazzola
oVirt Node 4.4.9.3 Async update
On December 15th 2021 the oVirt project released an async update of oVirt
Node (4.4.9.3) delivering fixes for the following issues:
Bug 2031911 <https://bugzilla.redhat.com/show_bug.cgi?id=2031911> - oVirt
Node 4.4.9.1 and 4.4.9.2 are missing UEFI support due to a build issue
Bug 2026432 <https://bugzilla.redhat.com/show_bug.cgi?id=2026432> -
rsyslog-openssl is missing
Reverted lvm2 package to previous version as workaround for
Bug 2026370 <https://bugzilla.redhat.com/show_bug.cgi?id=2026370> - oVirt
node fail to boot if lvm filter uses /dev/disk/by-id/lvm-pv-uuid-*
Several bug fixes and improvements from CentOS Stream.
Here’s the full list of changes:
--- ovirt-node-ng-image-4.4.9.2.manifest-rpm 2021-12-10
09:09:24.084642608 +0100
+++ ovirt-node-ng-image-4.4.9.3.manifest-rpm 2021-12-15
15:40:13.501764699 +0100
@@ -1,0 +2 @@
+ModemManager-glib-1.18.2-1.el8.x86_64
@@ -46,0 +48 @@
+bubblewrap-0.4.0-1.el8.x86_64
@@ -97,3 +99,3 @@
-dbus-1.12.8-14.el8.x86_64
-dbus-common-1.12.8-14.el8.noarch
-dbus-daemon-1.12.8-14.el8.x86_64
+dbus-1.12.8-18.el8.x86_64
+dbus-common-1.12.8-18.el8.noarch
+dbus-daemon-1.12.8-18.el8.x86_64
@@ -101,6 +103,6 @@
-dbus-libs-1.12.8-14.el8.x86_64
-dbus-tools-1.12.8-14.el8.x86_64
-device-mapper-1.02.181-1.el8.x86_64
-device-mapper-event-1.02.181-1.el8.x86_64
-device-mapper-event-libs-1.02.181-1.el8.x86_64
-device-mapper-libs-1.02.181-1.el8.x86_64
+dbus-libs-1.12.8-18.el8.x86_64
+dbus-tools-1.12.8-18.el8.x86_64
+device-mapper-1.02.177-10.el8.x86_64
+device-mapper-event-1.02.177-10.el8.x86_64
+device-mapper-event-libs-1.02.177-10.el8.x86_64
+device-mapper-libs-1.02.177-10.el8.x86_64
@@ -109 +111 @@
-device-mapper-persistent-data-0.9.0-5.el8.x86_64
+device-mapper-persistent-data-0.9.0-6.el8.x86_64
@@ -117 +119 @@
-dnf-plugins-core-4.0.21-6.el8.noarch
+dnf-plugins-core-4.0.21-7.el8.noarch
@@ -127,0 +130,3 @@
+efi-filesystem-3-3.el8.noarch
+efibootmgr-16-1.el8.x86_64
+efivar-libs-37-4.el8.x86_64
@@ -187,0 +193 @@
+fwupd-1.5.9-1.el8_4.x86_64
@@ -199,5 +205,5 @@
-glib2-2.56.4-157.el8.x86_64
-glibc-2.28-170.el8.x86_64
-glibc-common-2.28-170.el8.x86_64
-glibc-gconv-extra-2.28-170.el8.x86_64
-glibc-langpack-en-2.28-170.el8.x86_64
+glib2-2.56.4-158.el8.x86_64
+glibc-2.28-174.el8.x86_64
+glibc-common-2.28-174.el8.x86_64
+glibc-gconv-extra-2.28-174.el8.x86_64
+glibc-langpack-en-2.28-174.el8.x86_64
@@ -229,0 +236 @@
+grub2-efi-x64-2.02-106.el8.x86_64
@@ -251,0 +259 @@
+iotop-0.6-16.el8.noarch
@@ -274,13 +282,13 @@
-iwl100-firmware-39.31.5.1-103.el8.1.noarch
-iwl1000-firmware-39.31.5.1-103.el8.1.noarch
-iwl105-firmware-18.168.6.1-103.el8.1.noarch
-iwl135-firmware-18.168.6.1-103.el8.1.noarch
-iwl2000-firmware-18.168.6.1-103.el8.1.noarch
-iwl2030-firmware-18.168.6.1-103.el8.1.noarch
-iwl3160-firmware-25.30.13.0-103.el8.1.noarch
-iwl5000-firmware-8.83.5.1_1-103.el8.1.noarch
-iwl5150-firmware-8.24.2.2-103.el8.1.noarch
-iwl6000-firmware-9.221.4.1-103.el8.1.noarch
-iwl6000g2a-firmware-18.168.6.1-103.el8.1.noarch
-iwl6050-firmware-41.28.5.1-103.el8.1.noarch
-iwl7260-firmware-25.30.13.0-103.el8.1.noarch
+iwl100-firmware-39.31.5.1-105.el8.1.noarch
+iwl1000-firmware-39.31.5.1-105.el8.1.noarch
+iwl105-firmware-18.168.6.1-105.el8.1.noarch
+iwl135-firmware-18.168.6.1-105.el8.1.noarch
+iwl2000-firmware-18.168.6.1-105.el8.1.noarch
+iwl2030-firmware-18.168.6.1-105.el8.1.noarch
+iwl3160-firmware-25.30.13.0-105.el8.1.noarch
+iwl5000-firmware-8.83.5.1_1-105.el8.1.noarch
+iwl5150-firmware-8.24.2.2-105.el8.1.noarch
+iwl6000-firmware-9.221.4.1-105.el8.1.noarch
+iwl6000g2a-firmware-18.168.6.1-105.el8.1.noarch
+iwl6050-firmware-41.28.5.1-105.el8.1.noarch
+iwl7260-firmware-25.30.13.0-105.el8.1.noarch
@@ -332,15 +340,15 @@
-libblockdev-2.24-7.el8.x86_64
-libblockdev-crypto-2.24-7.el8.x86_64
-libblockdev-dm-2.24-7.el8.x86_64
-libblockdev-fs-2.24-7.el8.x86_64
-libblockdev-kbd-2.24-7.el8.x86_64
-libblockdev-loop-2.24-7.el8.x86_64
-libblockdev-lvm-2.24-7.el8.x86_64
-libblockdev-mdraid-2.24-7.el8.x86_64
-libblockdev-mpath-2.24-7.el8.x86_64
-libblockdev-nvdimm-2.24-7.el8.x86_64
-libblockdev-part-2.24-7.el8.x86_64
-libblockdev-plugins-all-2.24-7.el8.x86_64
-libblockdev-swap-2.24-7.el8.x86_64
-libblockdev-utils-2.24-7.el8.x86_64
-libblockdev-vdo-2.24-7.el8.x86_64
+libblockdev-2.24-8.el8.x86_64
+libblockdev-crypto-2.24-8.el8.x86_64
+libblockdev-dm-2.24-8.el8.x86_64
+libblockdev-fs-2.24-8.el8.x86_64
+libblockdev-kbd-2.24-8.el8.x86_64
+libblockdev-loop-2.24-8.el8.x86_64
+libblockdev-lvm-2.24-8.el8.x86_64
+libblockdev-mdraid-2.24-8.el8.x86_64
+libblockdev-mpath-2.24-8.el8.x86_64
+libblockdev-nvdimm-2.24-8.el8.x86_64
+libblockdev-part-2.24-8.el8.x86_64
+libblockdev-plugins-all-2.24-8.el8.x86_64
+libblockdev-swap-2.24-8.el8.x86_64
+libblockdev-utils-2.24-8.el8.x86_64
+libblockdev-vdo-2.24-8.el8.x86_64
@@ -363 +371 @@
-libdnf-0.63.0-4.el8.x86_64
+libdnf-0.63.0-5.el8.x86_64
@@ -372 +380,2 @@
-libgcc-8.5.0-4.el8_5.x86_64
+libgcab1-1.1-1.el8.x86_64
+libgcc-8.5.0-6.el8.x86_64
@@ -384 +393 @@
-libgomp-8.5.0-4.el8_5.x86_64
+libgomp-8.5.0-6.el8.x86_64
@@ -390,0 +400 @@
+libgusb-0.3.0-1.el8.x86_64
@@ -404 +414 @@
-libldb-2.3.0-2.el8.x86_64
+libldb-2.4.1-1.el8.x86_64
@@ -407,0 +418 @@
+libmbim-1.26.0-2.el8.x86_64
@@ -435,0 +447 @@
+libqmi-1.30.2-1.el8.x86_64
@@ -458,0 +471 @@
+libsmbios-2.4.1-2.el8.x86_64
@@ -470 +483 @@
-libstdc++-8.5.0-4.el8_5.x86_64
+libstdc++-8.5.0-6.el8.x86_64
@@ -472 +485 @@
-libtalloc-2.3.2-1.el8.x86_64
+libtalloc-2.3.3-1.el8.x86_64
@@ -475 +488 @@
-libtdb-1.4.3-1.el8.x86_64
+libtdb-1.4.4-1.el8.x86_64
@@ -493,24 +506,24 @@
-libvirt-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
-libvirt-client-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
-libvirt-daemon-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
-libvirt-daemon-config-network-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
-libvirt-daemon-config-nwfilter-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
-libvirt-daemon-driver-interface-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
-libvirt-daemon-driver-network-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
-libvirt-daemon-driver-nodedev-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
-libvirt-daemon-driver-nwfilter-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
-libvirt-daemon-driver-qemu-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
-libvirt-daemon-driver-secret-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
-libvirt-daemon-driver-storage-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
-libvirt-daemon-driver-storage-core-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
-libvirt-daemon-driver-storage-disk-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
-libvirt-daemon-driver-storage-gluster-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
-libvirt-daemon-driver-storage-iscsi-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
-libvirt-daemon-driver-storage-iscsi-direct-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
-libvirt-daemon-driver-storage-logical-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
-libvirt-daemon-driver-storage-mpath-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
-libvirt-daemon-driver-storage-rbd-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
-libvirt-daemon-driver-storage-scsi-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
-libvirt-daemon-kvm-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
-libvirt-libs-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
-libvirt-lock-sanlock-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
+libvirt-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
+libvirt-client-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
+libvirt-daemon-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
+libvirt-daemon-config-network-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
+libvirt-daemon-config-nwfilter-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
+libvirt-daemon-driver-interface-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
+libvirt-daemon-driver-network-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
+libvirt-daemon-driver-nodedev-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
+libvirt-daemon-driver-nwfilter-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
+libvirt-daemon-driver-qemu-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
+libvirt-daemon-driver-secret-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
+libvirt-daemon-driver-storage-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
+libvirt-daemon-driver-storage-core-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
+libvirt-daemon-driver-storage-disk-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
+libvirt-daemon-driver-storage-gluster-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
+libvirt-daemon-driver-storage-iscsi-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
+libvirt-daemon-driver-storage-iscsi-direct-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
+libvirt-daemon-driver-storage-logical-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
+libvirt-daemon-driver-storage-mpath-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
+libvirt-daemon-driver-storage-rbd-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
+libvirt-daemon-driver-storage-scsi-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
+libvirt-daemon-kvm-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
+libvirt-libs-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
+libvirt-lock-sanlock-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
@@ -528,0 +542 @@
+libxmlb-0.1.15-1.el8.x86_64
@@ -533 +547 @@
-linux-firmware-20210702-103.gitd79c2677.el8.noarch
+linux-firmware-20211119-105.gitf5d51956.el8.noarch
@@ -536 +550 @@
-llvm-compat-libs-12.0.1-3.module_el8.6.0+1029+6594c364.x86_64
+llvm-compat-libs-12.0.1-4.module_el8.6.0+1041+0c503ac4.x86_64
@@ -546,2 +560,2 @@
-lvm2-2.03.14-1.el8.x86_64
-lvm2-libs-2.03.14-1.el8.x86_64
+lvm2-2.03.12-10.el8.x86_64
+lvm2-libs-2.03.12-10.el8.x86_64
@@ -557,0 +572 @@
+memtest86+-5.01-20.el8.x86_64
@@ -564,0 +580 @@
+mokutil-0.3.0-11.el8.x86_64
@@ -590 +606 @@
-nftables-0.9.3-23.el8.x86_64
+nftables-0.9.3-24.el8.x86_64
@@ -593,2 +609,2 @@
-nmstate-1.2.0-0.1.alpha1.el8.noarch
-nmstate-plugin-ovsdb-1.2.0-0.1.alpha1.el8.noarch
+nmstate-1.2.0-0.1.alpha2.el8.x86_64
+nmstate-plugin-ovsdb-1.2.0-0.1.alpha2.el8.noarch
@@ -628,2 +644,2 @@
-ovirt-host-4.4.8-1.el8.x86_64
-ovirt-host-dependencies-4.4.8-1.el8.x86_64
+ovirt-host-4.4.9-2.el8.x86_64
+ovirt-host-dependencies-4.4.9-2.el8.x86_64
@@ -635 +651 @@
-ovirt-node-ng-image-update-placeholder-4.4.9.2-1.el8.noarch
+ovirt-node-ng-image-update-placeholder-4.4.9.3-1.el8.noarch
@@ -643,2 +659,2 @@
-ovirt-release-host-node-4.4.9.2-1.el8.noarch
-ovirt-release44-4.4.9.2-1.el8.noarch
+ovirt-release-host-node-4.4.9.3-1.el8.noarch
+ovirt-release44-4.4.9.3-1.el8.noarch
@@ -732 +748 @@
-python3-blockdev-2.24-7.el8.x86_64
+python3-blockdev-2.24-8.el8.x86_64
@@ -750,2 +766,2 @@
-python3-dnf-plugin-versionlock-4.0.21-6.el8.noarch
-python3-dnf-plugins-core-4.0.21-6.el8.noarch
+python3-dnf-plugin-versionlock-4.0.21-7.el8.noarch
+python3-dnf-plugins-core-4.0.21-7.el8.noarch
@@ -764 +780 @@
-python3-hawkey-0.63.0-4.el8.x86_64
+python3-hawkey-0.63.0-5.el8.x86_64
@@ -780 +796 @@
-python3-libdnf-0.63.0-4.el8.x86_64
+python3-libdnf-0.63.0-5.el8.x86_64
@@ -782 +798 @@
-python3-libnmstate-1.2.0-0.1.alpha1.el8.noarch
+python3-libnmstate-1.2.0-0.1.alpha2.el8.noarch
@@ -787 +803 @@
-python3-libvirt-7.9.0-1.module_el8.6.0+983+a7505f3f.x86_64
+python3-libvirt-7.10.0-1.module_el8.6.0+1046+bd8eec5e.x86_64
@@ -789 +805 @@
-python3-linux-procfs-0.6.3-3.el8.noarch
+python3-linux-procfs-0.6.3-4.el8.noarch
@@ -798 +814 @@
-python3-nftables-0.9.3-23.el8.x86_64
+python3-nftables-0.9.3-24.el8.x86_64
@@ -853 +869 @@
-python3-setools-4.3.0-2.el8.x86_64
+python3-setools-4.3.0-3.el8.x86_64
@@ -906,0 +923 @@
+rsyslog-openssl-8.2102.0-6.el8.x86_64
@@ -920,2 +937,2 @@
-selinux-policy-3.14.3-84.el8.noarch
-selinux-policy-targeted-3.14.3-84.el8.noarch
+selinux-policy-3.14.3-85.el8.noarch
+selinux-policy-targeted-3.14.3-85.el8.noarch
@@ -926 +943,3 @@
-shadow-utils-4.6-15.el8.x86_64
+shadow-utils-4.6-16.el8.x86_64
+shared-mime-info-1.9-3.el8.x86_64
+shim-x64-15-15.el8_2.x86_64
@@ -931 +950 @@
-sos-4.2-6.el8.noarch
+sos-4.2-7.el8.noarch
@@ -946 +965 @@
-sudo-1.8.29-7.el8_4.1.x86_64
+sudo-1.8.29-8.el8.x86_64
@@ -956 +975 @@
-sysstat-11.7.3-6.el8.x86_64
+sysstat-11.7.3-7.el8.x86_64
@@ -989,3 +1008,3 @@
-virt-install-3.2.0-1.el8.noarch
-virt-manager-common-3.2.0-1.el8.noarch
-virt-v2v-1.42.0-16.module_el8.6.0+983+a7505f3f.x86_64
+virt-install-3.2.0-2.el8.noarch
+virt-manager-common-3.2.0-2.el8.noarch
+virt-v2v-1.42.0-18.module_el8.6.0+1046+bd8eec5e.x86_64
@@ -995 +1014 @@
-xfsprogs-5.0.0-9.el8.x86_64
+xfsprogs-5.0.0-10.el8.x86_64
--
Sandro Bonazzola
MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV
Red Hat EMEA <https://www.redhat.com/>
sbonazzo(a)redhat.com
<https://www.redhat.com/>
*Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.*
3 years
import vm from iscsi storage domain fails with "Cannot import VM. Invalid time zone for given OS type. Attribute: vm.vmStatic"
by timo.veith＠uni-tuebingen.de
Dear ovirt users,
we are running RHV 4.4.8.6-0.1.el8ev on the manager and Red Hat Virtualization Host 4.4.6 (el8.4) on the hypervisors. Normally I would open a case at Red Hat but our subscriptions expired. We are currently in the process of purchasing new ones but this problem is really urgent so I thought I'd give it a try here. Sorry for that if its misplaced.
We have a problem importing some VMs from a iscsi storage domain. We had an outage of the iscsi san volume but managed to recover the data and bring them back online. We imported the volume into a new data center and were able to import most of the vms which were on that volume. But now there are still some importand ones left and we do get the upper mentioned error.
I searched the web and found a solution which proposes to alter the "operating system type" in the import dialog and change it to "linux". Oh, while writing "linux" I forgot to mention all of the problematic vms are windows ones. But the import dialog doesn't let me change the operation system type. I can only change the name.
I found another solution here in the archive of this mailing list. Its pretty new I think. Topic was "How to re-import a VM with an invalid timezone?" in August. The solution was to add the missing timezone in a file (https://github.com/oVirt/ovirt-engine/blob/master/packaging/conf/timezone...) on the manager and restart ovirt-engine. I would love to try that but I really don't know what to put there. I can't open an ova file because the vm is on the iscsi domain in some lvs or metadata or .. I don't know where RHV reads that from.
Hope I am not missing some important info. Any help would be greatly appreciated
Cheers
Timo
3 years
Re: remote-viewer VNC mode issue
by Patrick Hibbs
Hello,
Well a quick check of the hosts say that they have ovirt-
vmconsole enabled on their firewall, but there doesn't seem to be any
logs for the vmconsoles on them. Running wireshark on one of the end-
user machines shows that the host does send packets back and forth but
then the end-user machine TCP resets the connection. (I assume due to
the credential failure.) So it doesn't seem to be a firewall issue.
Is there anything I can do to get some more logs from the vmconsoles on
the Host?
Thanks.
-Patrick Hibbs
On Tue, 2021-12-14 at 12:56 +0000, Staniforth, Paul wrote:
> Hello Patrick,
> with noVNC the connection is made via the
> websocket-poxy service (probably on the engine server).
> The remote-viewer connects directly from the client machine to the
> virtual host the VM is running on. Maybe check the network/firewall
> between the client and the host, also the OTP expires after 120
> seconds.
>
>
> Regards,
>
> Paul S.
> From: Strahil Nikolov via Users <users(a)ovirt.org>
> Sent: 14 December 2021 12:12
> To: hibbsncc1701(a)gmail.com <hibbsncc1701(a)gmail.com>; oVirt Users
> Mailing List <users(a)ovirt.org>
> Subject: [ovirt-users] Re: remote-viewer VNC mode issue
> Caution External Mail: Do not click any links or open any attachments
> unless you trust the sender and know that the content is safe.
> The most common problem is the CA of oVirt not trusted in the web
> browser of the client.
>
>
> Best Regards,
> Strahil Nikolov
>
> > On Sun, Dec 12, 2021 at 0:00, Patrick Hibbs
> > <hibbsncc1701(a)gmail.com> wrote:
> > Hello,
> >
> > As oVirt unfortuately now requires VNC for the VM consoles,
> > I've been attempting to get VNC mode working on my end user
> > clients.
> >
> > The noVNC browser client works just fine, but for some reason
> > the default download to remote-viewer fails on the same hosts.
> >
> > All the end-user gets is a quick flash of the remote-viewer window
> > on
> > their screen.
> >
> > Running remote-viewer in debug mode I get this:
> >
> > ---log snip---
> >
> > $ remote-viewer -v --debug Downloads/console.vv
> > (remote-viewer:4056): virt-viewer-DEBUG: 16:35:35.906: Opening
> > display
> > to Downloads/console.vv
> > (remote-viewer:4056): virt-viewer-DEBUG: 16:35:35.906: Guest (null)
> > has
> > a vnc display
> > Guest (null) has a vnc display
> > (remote-viewer:4056): virt-viewer-DEBUG: 16:35:35.952: Spice
> > foreign
> > menu updated
> > (remote-viewer:4056): virt-viewer-DEBUG: 16:35:35.952: After open
> > connection callback fd=-1
> > (remote-viewer:4056): virt-viewer-DEBUG: 16:35:35.952: Opening
> > connection to display at Downloads/console.vv
> > Opening connection to display at Downloads/console.vv
> > (remote-viewer:4056): virt-viewer-DEBUG: 16:35:35.953: fullscreen
> > display 0: 0
> > (remote-viewer:4056): virt-viewer-DEBUG: 16:35:35.953: notebook
> > show
> > status 0x560a419d2280
> > (remote-viewer:4056): virt-viewer-DEBUG: 16:35:36.032: notebook
> > show
> > status 0x560a419d2280
> > (remote-viewer:4056): virt-viewer-DEBUG: 16:35:36.032: Insert
> > display 0
> > 0x560a423fa1e0
> > (remote-viewer:4056): virt-viewer-DEBUG: 16:35:36.032: notebook
> > show
> > status 0x560a419d2280
> > (remote-viewer:4056): virt-viewer-DEBUG: 16:35:36.052: Allocated
> > 1024x740
> > (remote-viewer:4056): virt-viewer-DEBUG: 16:35:36.052: Child
> > allocate
> > 1024x640
> > (remote-viewer:4056): virt-viewer-DEBUG: 16:35:36.053: Got VNC
> > credential request for 1 credential(s)
> > (remote-viewer:4056): virt-viewer-DEBUG: 16:35:36.067: Not removing
> > main window 0 0x560a4195d910
> > (remote-viewer:4056): virt-viewer-DEBUG: 16:35:36.067: Disconnected
> > (remote-viewer:4056): virt-viewer-DEBUG: 16:35:36.067: close
> > vnc=0x560a419fc220
> > (remote-viewer:4056): virt-viewer-DEBUG: 16:35:36.068: notebook
> > show
> > status 0x560a419d2280
> > (remote-viewer:4056): virt-viewer-DEBUG: 16:35:36.068: Guest (null)
> > display has disconnected, shutting down
> > Guest (null) display has disconnected, shutting down
> >
> > ---log snip---
> >
> > It seems to be failing a credential request, but I'm not sure why.
> > The
> > engine logs only show the VM console ticket being created, but does
> > not
> > show any connection attempts unless noVNC is used.
> >
> > ---log snip---
> >
> > 2021-12-11 16:48:23,402-05 INFO
> > [org.ovirt.engine.core.bll.SetVmTicketCommand] (default task-16)
> > [68b90cfe] Running command: SetVmTicketCommand internal: false.
> > Entities affected : ID: bb05ab12-91e5-4ab6-92b1-b911ed78f64f Type:
> > VMAction group CONNECT_TO_VM with role type USER
> > 2021-12-11 16:48:23,414-05 INFO
> > [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand]
> > (default task-16) [68b90cfe] START, SetVmTicketVDSCommand(HostName
> > = --
> > REDACTED--, SetVmTicketVDSCommandParameters:{hostId='1fdd841b-477f-
> > 4d13-9935-7908924dd5a1', vmId='bb05ab12-91e5-4ab6-92b1-
> > b911ed78f64f',
> > protocol='VNC', ticket='ocziPsEOF4km', validTime='120', userName='--
> > REDACTED--@--REDACTED--', userId='e83ab2b3-c464-49a4-a0ab-
> > 4e62e8131304', disconnectAction='LOCK_SCREEN'}), log id: f6dccdd
> > 2021-12-11 16:48:23,435-05 INFO
> > [org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand]
> > (default task-16) [68b90cfe] FINISH, SetVmTicketVDSCommand, return:
> > ,
> > log id: f6dccdd
> > 2021-12-11 16:48:23,461-05 INFO
> > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirect
> > or]
> > (default task-16) [68b90cfe] EVENT_ID: VM_SET_TICKET(164), User --
> > REDACTED--@--REDACTED--@--REDACTED-- initiated console session for
> > VM
> > Test
> > #
> >
> > ---log snip---
> >
> > What else can I do to troubleshoot this?
> >
> > - Patrick Hibbs
> >
> > _______________________________________________
> > Users mailing list -- users(a)ovirt.org
> > To unsubscribe send an email to users-leave(a)ovirt.org
> > Privacy Statement: https://www.ovirt.org/privacy-policy.html
> > oVirt Code of Conduct:
> > https://www.ovirt.org/community/about/community-guidelines/
> > List Archives:
> >
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/Q5ENXJJU5V7...
> To view the terms under which this email is distributed, please go
> to:-
> https://leedsbeckett.ac.uk/disclaimer/email
3 years
remote-viewer VNC mode issue
by Patrick Hibbs
Hello,
As oVirt unfortuately now requires VNC for the VM consoles,
I've been attempting to get VNC mode working on my end user clients.
The noVNC browser client works just fine, but for some reason
the default download to remote-viewer fails on the same hosts.
All the end-user gets is a quick flash of the remote-viewer window on
their screen.
Running remote-viewer in debug mode I get this:
---log snip---
$ remote-viewer -v --debug Downloads/console.vv
(remote-viewer:4056): virt-viewer-DEBUG: 16:35:35.906: Opening display
to Downloads/console.vv
(remote-viewer:4056): virt-viewer-DEBUG: 16:35:35.906: Guest (null) has
a vnc display
Guest (null) has a vnc display
(remote-viewer:4056): virt-viewer-DEBUG: 16:35:35.952: Spice foreign
menu updated
(remote-viewer:4056): virt-viewer-DEBUG: 16:35:35.952: After open
connection callback fd=-1
(remote-viewer:4056): virt-viewer-DEBUG: 16:35:35.952: Opening
connection to display at Downloads/console.vv
Opening connection to display at Downloads/console.vv
(remote-viewer:4056): virt-viewer-DEBUG: 16:35:35.953: fullscreen
display 0: 0
(remote-viewer:4056): virt-viewer-DEBUG: 16:35:35.953: notebook show
status 0x560a419d2280
(remote-viewer:4056): virt-viewer-DEBUG: 16:35:36.032: notebook show
status 0x560a419d2280
(remote-viewer:4056): virt-viewer-DEBUG: 16:35:36.032: Insert display 0
0x560a423fa1e0
(remote-viewer:4056): virt-viewer-DEBUG: 16:35:36.032: notebook show
status 0x560a419d2280
(remote-viewer:4056): virt-viewer-DEBUG: 16:35:36.052: Allocated
1024x740
(remote-viewer:4056): virt-viewer-DEBUG: 16:35:36.052: Child allocate
1024x640
(remote-viewer:4056): virt-viewer-DEBUG: 16:35:36.053: Got VNC
credential request for 1 credential(s)
(remote-viewer:4056): virt-viewer-DEBUG: 16:35:36.067: Not removing
main window 0 0x560a4195d910
(remote-viewer:4056): virt-viewer-DEBUG: 16:35:36.067: Disconnected
(remote-viewer:4056): virt-viewer-DEBUG: 16:35:36.067: close
vnc=0x560a419fc220
(remote-viewer:4056): virt-viewer-DEBUG: 16:35:36.068: notebook show
status 0x560a419d2280
(remote-viewer:4056): virt-viewer-DEBUG: 16:35:36.068: Guest (null)
display has disconnected, shutting down
Guest (null) display has disconnected, shutting down
---log snip---
It seems to be failing a credential request, but I'm not sure why. The
engine logs only show the VM console ticket being created, but does not
show any connection attempts unless noVNC is used.
---log snip---
2021-12-11 16:48:23,402-05 INFO
[org.ovirt.engine.core.bll.SetVmTicketCommand] (default task-16)
[68b90cfe] Running command: SetVmTicketCommand internal: false.
Entities affected : ID: bb05ab12-91e5-4ab6-92b1-b911ed78f64f Type:
VMAction group CONNECT_TO_VM with role type USER
2021-12-11 16:48:23,414-05 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand]
(default task-16) [68b90cfe] START, SetVmTicketVDSCommand(HostName = --
REDACTED--, SetVmTicketVDSCommandParameters:{hostId='1fdd841b-477f-
4d13-9935-7908924dd5a1', vmId='bb05ab12-91e5-4ab6-92b1-b911ed78f64f',
protocol='VNC', ticket='ocziPsEOF4km', validTime='120', userName='--
REDACTED--@--REDACTED--', userId='e83ab2b3-c464-49a4-a0ab-
4e62e8131304', disconnectAction='LOCK_SCREEN'}), log id: f6dccdd
2021-12-11 16:48:23,435-05 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.SetVmTicketVDSCommand]
(default task-16) [68b90cfe] FINISH, SetVmTicketVDSCommand, return: ,
log id: f6dccdd
2021-12-11 16:48:23,461-05 INFO
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(default task-16) [68b90cfe] EVENT_ID: VM_SET_TICKET(164), User --
REDACTED--@--REDACTED--@--REDACTED-- initiated console session for VM
Test
#
---log snip---
What else can I do to troubleshoot this?
- Patrick Hibbs
3 years
Issue with DWH Installtion "Failed to execute stage 'Misc configuration': terminating connection due to administrator command"
by Maitler
Issue with oVirt fresh install, during step 3.5 'Installing and Configuring Data Warehouse on a Separate Machine':
Following Guide: Installing oVirt as a standalone Engine with remote databases
The two nodes; ovirt-net and ovirt-ctl are both fresh installed RHEL 8.4 nodes, built to make this test environment. With ovirt-ctl being the engine host and ovirt-net hosting the postgres database and DWH services.
Upon following the steps through the engine-setup after confirming the installation settings, the setup gets to '[INFO] Creating a user for Grafana' then says the following error:
[ ERROR ] Failed to execute stage 'Misc configuration': terminating connection due to administrator command
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
Afterwards within /etc/pki/ovirt-engine/ there's broken/empty symbolic links for apache certs and keys linking to apache-grafana which'll cause errors for further attempts are re-doing the engine-setup.
Here's the lines before and after the error in the output log from the setup:
2021-12-06 14:49:08,233-0330 DEBUG otopi.ovirt_engine_setup.engine_common.database database.execute:234 Database: 'None', Statement: '
select * from GetDwhHistoryTimekeepingByVarName(
%(name)s
)
', args: {'name': 'dwhHostname'}
2021-12-06 14:49:08,233-0330 DEBUG otopi.ovirt_engine_setup.engine_common.database database.execute:239 Creating own connection
2021-12-06 14:49:08,253-0330 DEBUG otopi.ovirt_engine_setup.engine_common.database database.execute:284 Result: [{'var_name': 'dwhHostname', 'var_value': None, 'var_datetime': None}]
2021-12-06 14:49:08,254-0330 DEBUG otopi.ovirt_engine_setup.engine_common.database database.execute:234 Database: 'None', Statement: '
select UpdateDwhHistoryTimekeeping(
%(name)s,
%(value)s,
NULL
)
', args: {'name': 'dwhHostname', 'value': 'cloud-ovirt-net.mun.cluster.dns'}
2021-12-06 14:49:08,254-0330 DEBUG otopi.context context._executeMethod:145 method exception
Traceback (most recent call last):
File "/usr/lib/python3.6/site-packages/otopi/context.py", line 132, in _executeMethod
method['method']()
File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine-dwh/core/single_etl.py", line 167, in _misc
value=self.environment[osetupcons.ConfigEnv.FQDN]
File "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/dwh_history_timekeeping.py", line 63, in updateValueInTimekeeping
ownConnection=False,
File "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/database.py", line 258, in execute
args,
psycopg2.OperationalError: terminating connection due to administrator command
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
2021-12-06 14:49:08,257-0330 ERROR otopi.context context._executeMethod:154 Failed to execute stage 'Misc configuration': terminating connection due to administrator command
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
2021-12-06 14:49:08,257-0330 DEBUG otopi.plugins.otopi.dialog.human human.format:69 newline sent to logger
2021-12-06 14:49:08,258-0330 DEBUG otopi.transaction transaction.abort:124 aborting 'DNF Transaction'
3 years
oVirt and log4j vulnerability
by Chris Adams
Can an oVirt developer comment about the log4j vulnerability - is
oVirt's use of log4j vulnerable?
--
Chris Adams <cma(a)cmadams.net>
3 years
Upgrading 4.3.7 -> 4.4.9 :: Can't migrate vm from old to new host
by Niklas Larsson
Hi,
we are trying to upgrade 4.3.7 -> 4.4.9 (Ovirt-Node, hosted engine). And
things looks good until we try to migrate VM from 4.3.7 host to the
4.4.9 host, it fails with an generic error - and in below is from the
vsdm.log from the 4.3.7 host.
Migrating VM from 4.4.9 host -> 4.3.7 host works.
Upgraded the 4.3.7 to 4.3.10 - did not solve it
Log from the 4.3 host:
2021-12-10 16:18:22,829+0100 INFO (jsonrpc/1) [api.virt] START
migrate(params={u'incomingLimit': 2, u'src':
u'kvm22.shg.mgn.weblink.se', u'dstqemu': u'10.1.2.111', u'autoConverge':
u'true', u'tunneled': u'false', u'enableGuestEvents': T
rue, u'dst': u'kvm21.shg.mgn.weblink.se:54321', u'convergenceSchedule':
{u'init': [{u'params': [u'100'], u'name': u'setDowntime'}], u'stalling':
[{u'action': {u'params': [u'150'], u'name': u'setDowntime'}, u'limit':
1}, {u'action': {u'params': [u'200'], u'name': u'setDowntime'},
u'limit': 2}, {u'action': {u'params': [u'300'], u'name':
u'setDowntime'}, u'limit': 3}, {u'action': {u'params': [u'400'],
u'name': u'setDowntime'}, u'limit': 4}, {u'action': {u'params':
[u'500'], u'name': u'setDowntime'}, u'limit': 6}, {u'action':
{u'params': [], u'name': u'abort'}, u'limit': -1}]}, u'vmId':
u'11f3a2aa-7951-4064-92f9-bb8ab515373b', u'abortOnError': u'true',
u'outgoingLimit': 2, u'compressed': u'false', u'maxBandwidth': 62,
u'method': u'online'}) from=::ffff:10.1.2.51,46546,
flow_id=03aca28c-00c9-4b58-a1e8-3aa355e162c2,
vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:48)
2021-12-10 16:18:22,831+0100 INFO (jsonrpc/1) [api.virt] FINISH migrate
return={'status': {'message': 'Migration in progress', 'code': 0},
'progress': 0} from=::ffff:10.1.2.51,46546,
flow_id=03aca28c-00c9-4b58-a1e8-3aa355e162c2,
vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:54)
2021-12-10 16:18:22,831+0100 INFO (jsonrpc/1) [jsonrpc.JsonRpcServer]
RPC call VM.migrate succeeded in 0.01 seconds (__init__:312)
2021-12-10 16:18:22,873+0100 ERROR (migsrc/11f3a2aa) [virt.vm]
(vmId='11f3a2aa-7951-4064-92f9-bb8ab515373b') [Errno -2] Name or service
not known (migration:282)
2021-12-10 16:18:22,875+0100 ERROR (migsrc/11f3a2aa) [virt.vm]
(vmId='11f3a2aa-7951-4064-92f9-bb8ab515373b') Failed to migrate
(migration:450)
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py", line
402, in _regular_run
self._setupVdsConnection()
File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py", line
239, in _setupVdsConnection
client = self._createClient(port)
File "/usr/lib/python2.7/site-packages/vdsm/virt/migration.py", line
227, in _createClient
client_socket = utils.create_connected_socket(host, int(port), sslctx)
File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 435, in
create_connected_socket
socket.AF_UNSPEC, socket.SOCK_STREAM)
gaierror: [Errno -2] Name or service not known
2021-12-10 16:18:22,888+0100 INFO (jsonrpc/7) [api.virt] START
getMigrationStatus() from=::ffff:10.1.2.51,46546,
vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:48)
2021-12-10 16:18:22,888+0100 INFO (jsonrpc/7) [api.virt] FINISH
getMigrationStatus return={'status': {'message': 'Done', 'code': 0},
'migrationStats': {'status': {'message': 'Fatal error during migration',
'code': 12}, 'progress': 0}} from=::ffff:10.1.2.51,46546,
vmId=11f3a2aa-7951-4064-92f9-bb8ab515373b (api:54)
2021-12-10 16:18:22,889+0100 INFO (jsonrpc/7) [jsonrpc.JsonRpcServer]
RPC call VM.getMigrationStatus succeeded in 0.00 seconds (__init__:312)
2021-12-10 16:18:23,431+0100 INFO (jsonrpc/3) [jsonrpc.JsonRpcServer]
RPC call Host.ping2 succeeded in 0.00 seconds (__init__:312)
Any ideas?
/niklas
3 years
Varying degree of failures after updating from 4.4.8 to 4.4.9
by Paul-Erik Törrönen
I have a server running the engine on CentOS Stream.
2 hosts running likewise CentOS 8 Stream (C8S) and 2 hosts running
Rocky Linux 8.5 (RL8.5).
I had several VMs running on the 8S without any issue. After the oVirt
upgrade, which partially fails* on the C8S-machines, the VMs on the
C8S-hosts appear to be running, according to the oVirt GUI, but I can
neither ping, ssh or even open a virt-viewer console to the VM. The
console shows just a black screen.
The only thing shown in the GUI is a note that the guest agent should be
updated on the VM, so there appears to be some kind of communication
between the engine/host and the VM.
If I create a new VM on the C8S, I get the same result: No access to it,
console is black despite the fact that oVirt GUI shows the VM as running
and green.
If I create a VM on one of the RL8.5 hosts, the console does work, I can
eg. complete the GUI-installation (from CD) there. But after the boot,
despite having configured the network correctly in the oVirt-GUI and in
the installation process, the VM (using the console) is unable to raise
the network.
No error is displayed in the oVirt GUI neither for the cluster, DC, host
nor VM.
No apparent log-error neither in the engine-server nor the hosts.
Stopped the firewalld on both in the engine-server as well as the hosts,
but this did not change anything.
It seems that the 4.4.9-upgrade somehow broke the oVirt logical
networking, completely on C8S-hosts.
* The C8S hosts fail on update WRT the following packages:
Error:
Problem 1: package rsyslog-openssl-8.2102.0-5.el8.x86_64 requires
rsyslog = 8.2102.0-5.el8, but none of the providers can be installed
- cannot install both rsyslog-8.2102.0-6.el8.x86_64 and
rsyslog-8.2102.0-5.el8.x86_64
- cannot install the best update candidate for package
rsyslog-openssl-8.2102.0-5.el8.x86_64
- cannot install the best update candidate for package
rsyslog-8.2102.0-5.el8.x86_64
Problem 2: package ovirt-host-dependencies-4.4.9-2.el8.x86_64 requires
rsyslog-openssl, but none of the providers can be installed
- package rsyslog-openssl-8.2102.0-5.el8.x86_64 requires rsyslog =
8.2102.0-5.el8, but none of the providers can be installed
- cannot install both rsyslog-8.2102.0-6.el8.x86_64 and
rsyslog-8.2102.0-5.el8.x86_64
- package rsyslog-elasticsearch-8.2102.0-6.el8.x86_64 requires rsyslog
= 8.2102.0-6.el8, but none of the providers can be installed
- cannot install the best update candidate for package
rsyslog-elasticsearch-8.2102.0-5.el8.x86_64
- cannot install the best update candidate for package
ovirt-host-dependencies-4.4.9-2.el8.x86_64
Problem 3: problem with installed package
rsyslog-openssl-8.2102.0-5.el8.x86_64
- package rsyslog-openssl-8.2102.0-5.el8.x86_64 requires rsyslog =
8.2102.0-5.el8, but none of the providers can be installed
- cannot install both rsyslog-8.2102.0-6.el8.x86_64 and
rsyslog-8.2102.0-5.el8.x86_64
- package rsyslog-mmjsonparse-8.2102.0-6.el8.x86_64 requires rsyslog =
8.2102.0-6.el8, but none of the providers can be installed
- cannot install the best update candidate for package
rsyslog-mmjsonparse-8.2102.0-5.el8.x86_64
Problem 4: package ovirt-host-4.4.9-2.el8.x86_64 requires
ovirt-host-dependencies = 4.4.9-2.el8, but none of the providers can be
installed
- package ovirt-host-dependencies-4.4.9-2.el8.x86_64 requires
rsyslog-openssl, but none of the providers can be installed
- package rsyslog-openssl-8.2102.0-5.el8.x86_64 requires rsyslog =
8.2102.0-5.el8, but none of the providers can be installed
- cannot install both rsyslog-8.2102.0-6.el8.x86_64 and
rsyslog-8.2102.0-5.el8.x86_64
- package rsyslog-mmnormalize-8.2102.0-6.el8.x86_64 requires rsyslog =
8.2102.0-6.el8, but none of the providers can be installed
- cannot install the best update candidate for package
rsyslog-mmnormalize-8.2102.0-5.el8.x86_64
- cannot install the best update candidate for package
ovirt-host-4.4.9-2.el8.x86_64
The RL8.5 have no issues with the rsyslog-* packages which are:
rsyslog-8.2102.0-5.el8.x86_64
rsyslog-elasticsearch-8.2102.0-5.el8.x86_64
rsyslog-mmjsonparse-8.2102.0-5.el8.x86_64
rsyslog-mmnormalize-8.2102.0-5.el8.x86_64
rsyslog-openssl-8.2102.0-5.el8.x86_64
What can I still check at this point?
Poltsi
3 years
