Oracle Confidential


Devin,

The “dnf update” command is always the last command to run on the engine instance (guest OS and engine application) update process.

The update process always starts with the engine-upgrade-check command, the engine update/upgrade is run by the engine-setup command. In the end, “dnf update” will take care of the OS update/upgrade process.

Marcos



Oracle Confidential

From:
Devin A. Bougie <devin.bougie@cornell.edu>
Date: Thursday, 13 August 2026 at 15:24
To: Marcos Sungaila <marcos.sungaila@oracle.com>
Cc: users@ovirt.org <users@ovirt.org>
Subject: Re: [External] : [ovirt-users]Re: Yum repositories for 4.5.7 hosted engine VM

This Message Is From an External Sender
This message came from outside your organization.
 
Thanks again, Marcos! I followed the "Upgrading a self-hosted engine from oVirt 4.5.6 to 4.5.7” guide linked to at [1] below, which gave us an engine VM running AlmaLinux 9. Perhaps this is from our underlying hosts all being fully updated AlmaLinux 9? Step "11.8. Enabling the Engine repositories” has you end with installing the oVirt 4.5 repositories (they were already installed in our case), and then finishing with a "dnf update -y” on the engine. I see that the Oracle Virtualization guide also ends with a "dnf update” on the engine, but appreciate your advice against a simple “dnf update.” Happy to provide any more information or tests, but can also accept if best practice is to not do a “dnf update” and only update the engine with "engine-upgrade-check” and “engine-setup.” Thanks again, Devin [1] https://urldefense.com/v3/__https://www.ovirt.org/documentation/upgrade_guide/*SHE_Upgrading_from_4-5-6__;Iw!!ACWV5N9M2RV99hQ!MgmwG4bF4X__O1XgIH4rUD1eA-GIL_x4EIbGbTV4wRnxU8_eCyYaL3f_a2Zi5fN_hqMXFhI2dtHY_02DNLc_b29-1Jt7xw$ > On Aug 13, 2026, at 2:07 PM, Marcos Sungaila <marcos.sungaila@oracle.com> wrote: > > Devin, > > As I understand, the installed Engine will be the one available from the oVirt repos, which means that it will be a CentOS system. Can you confirm this? > If this is correct, all enabled repos are right, and you should be able to update or upgrade the engine following the proper Engine update process. Note that the update command is called engine-upgrade-check (yes, upgrade). > Simply running dnf update can break the engine. > I would restore all repos configurations before trying to update/upgrade it. > These are the steps from Oracle Virtualization, and are very similar to the one from oVirt. > https://docs.oracle.com/en/virtualization/oracle-linux-virtualization-manager/admin/admin-update-engine.html#update-engine > > Marcos > > > Oracle Confidential > From: Devin A. Bougie <devin.bougie@cornell.edu> > Date: Thursday, 13 August 2026 at 12:11 > To: Marcos Sungaila <marcos.sungaila@oracle.com> > Cc: users@ovirt.org <users@ovirt.org> > Subject: Re: [External] : [ovirt-users]Re: Yum repositories for 4.5.7 hosted engine VM > > This Message Is From an External Sender > This message came from outside your organization. > Report Suspicious > Thanks, Marcos! > > Just to be clear, I’m asking about the list of repos that are installed by default on a new self-hosted engine VM. Even with priorities as you describe and the ceph repos disabled entirely, I’m seeing conflicts between the installed packages and available updates. For now, I’m still disabling centos-opstools and appstream in order to do a clean “dnf update”. > > Please see below for the full output, but for example from my understanding: > - The installed python3-botocore requires python3-jmespath >= 0.7.1 and < 1.0, but appstream provides python3-jmespath-1.0.1-1.el9_7.noarch > - The installed python3-pyngus conflicts with python-qpid-proton from centos-opstools > > Thanks again, > Devin > > ——— > [root@lnxvirt-engine ~]# dnf update > Last metadata expiration check: 0:01:24 ago on Thu 13 Aug 2026 10:32:30 AM EDT. > Error: Problem 1: package python3-botocore-1.21.58-1.el9s.noarch from @System requires (python3.9dist(jmespath) < 1 with python3.9dist(jmespath) >= 0.7.1), but none of the providers can be installed > - cannot install both python3-jmespath-1.0.1-1.el9_7.noarch from appstream and python3-jmespath-0.10.0-1.el9s.noarch from @System > - cannot install both python3-jmespath-1.0.1-1.el9_7.noarch from appstream and python3-jmespath-0.10.0-1.el9s.noarch from centos-openstack-yoga > - cannot install the best update candidate for package python3-jmespath-0.10.0-1.el9s.noarch > - cannot install the best update candidate for package python3-botocore-1.21.58-1.el9s.noarch > Problem 2: package python3-pyngus-2.3.0-8.el9s.noarch from @System requires python3.9dist(python-qpid-proton), but none of the providers can be installed > - cannot install both python3-qpid-proton-0.39.0-2.el9s.x86_64 from centos-opstools and python3-qpid-proton-0.35.0-2.el9s.x86_64 from @System > - cannot install both python3-qpid-proton-0.39.0-2.el9s.x86_64 from centos-opstools and python3-qpid-proton-0.35.0-2.el9s.x86_64 from centos-openstack-yoga > - cannot install the best update candidate for package python3-qpid-proton-0.35.0-2.el9s.x86_64 > - cannot install the best update candidate for package python3-pyngus-2.3.0-8.el9s.noarch > Problem 3: package python3-oslo-messaging-12.13.3-1.el9s.noarch from @System requires python3-pyngus, but none of the providers can be installed > - package python3-pyngus-2.3.0-8.el9s.noarch from @System requires python3.9dist(python-qpid-proton), but none of the providers can be installed > - package python3-pyngus-2.3.0-8.el9s.noarch from centos-openstack-yoga requires python3.9dist(python-qpid-proton), but none of the providers can be installed > - package python3-qpid-proton-0.35.0-2.el9s.x86_64 from @System requires qpid-proton-c(x86-64) = 0.35.0-2.el9s, but none of the providers can be installed > - package python3-qpid-proton-0.35.0-2.el9s.x86_64 from centos-openstack-yoga requires qpid-proton-c(x86-64) = 0.35.0-2.el9s, but none of the providers can be installed > - cannot install both qpid-proton-c-0.39.0-2.el9s.x86_64 from centos-opstools and qpid-proton-c-0.35.0-2.el9s.x86_64 from @System > - cannot install both qpid-proton-c-0.39.0-2.el9s.x86_64 from centos-opstools and qpid-proton-c-0.35.0-2.el9s.x86_64 from centos-openstack-yoga > - cannot install the best update candidate for package qpid-proton-c-0.35.0-2.el9s.x86_64 > - cannot install the best update candidate for package python3-oslo-messaging-12.13.3-1.el9s.noarch > (try to add '--allowerasing' to command line to replace conflicting packages or '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) > ——— > > > On Aug 12, 2026, at 8:48 AM, Marcos Sungaila <marcos.sungaila@oracle.com> wrote: > > > > You don't often get email from marcos.sungaila@oracle.com. Learn why this is important Oracle Confidential > > > > Hi Konstantin > > > > Instead of disabling the repos, use priorities. Configure all distro repos as priority 10, and all oVirt/Ceph as priority 1. This will avoid conflicts and permit the proper packages to be installed. > > > > Marcos > > > > > > Oracle Confidential > > From: Konstantin Shalygin <k0ste@k0ste.ru> > > Date: Wednesday, 12 August 2026 at 05:35 > > To: Devin A. Bougie <devin.bougie@cornell.edu> > > Cc: users@ovirt.org <users@ovirt.org> > > Subject: [External] : [ovirt-users]Re: Yum repositories for 4.5.7 hosted engine VM > > > > This Message Is From a New Sender > > You have not previously corresponded with the sender of this message. > > Report Suspicious > > Hi > > > > On 11 Aug 2026, at 21:58, Devin A. Bougie via Users <users@ovirt.org> wrote: > > > > For now, I’ve removed the conflicts by disabling the appstream, centos-ceph-pacific, and centos-opstools repos. Any additional tips on which repos should be enabled and/or how to address the package conflicts would be greatly appreciated. > > > > Hundred times written on this list. Use el9 ceph repo for your setup > > > > https://urldefense.com/v3/__https://download.ceph.com/rpm-tentacle/el9__;!!ACWV5N9M2RV99hQ!Jo5f-zZfAU3USeABKwOBsUO4ISpooIMLopW5ZVyaK4x81EyRh61PGL7cbOPCMuXXSRkXmBL2TeHn_qNg_4wvVGf0umLU9A$ >> > > > > > > k > >