- Users - oVirt List Archives

oVirt 4.5.7 self-hosted Engine EL8 to EL9 upgrade
by mbucak＠bigpond.com 09 Nov '26

09 Nov '26

Hi, I'm running OLVM/oVirt 4.5.7 with a self-hosted Engine on Oracle Linux 8 and need to move the Engine to Oracle Linux 9. Oracle currently publishes an EL8 to EL9 upgrade procedure for a standalone Engine, but I haven't been able to find an equivalent procedure for a self-hosted Engine. I'm assuming an in-place OS upgrade isn't the recommended approach. What is the correct procedure for an existing self-hosted Engine? Is there an upstream oVirt guide covering an EL8 to EL9 migration, and has anyone successfully performed this with 4.5.7? Thanks, Klokanovic

2 1

self-hosted engine
by Diggy Mc 03 Nov '26

03 Nov '26

Has it been decided what distro and version the next self-hosted engine will be based on? If I have a vote, I choose Rocky 10. CentOS has too short of a lifecycle. Looking forward to oVirt 4.6. j/s

2 2

Future oVirt versions
by Diggy Mc 30 Oct '26

30 Oct '26

Is there a target release (or at least beta) date for the next major oVirt release, presumably 4.6 ??? Will it support Rocky Linux 10 nodes? What platform will the hosted-engine be built upon? Just planning ahead for our future redeployment. Thanks for any insight you can give.

5 7

Fwd: React-based WebAdmin modernization for oVirt Engine
by 정하늘 30 Oct '26

30 Oct '26

Hello oVirt maintainers, My name is Jeong Haneul, and I'm an infrastructure engineer from South Korea. First, I'd like to thank everyone who has contributed to oVirt over the years. I still provides virtualization solutions based on oVirt Engine, and we've relied on the project for a long time. As upstream development has slowed, I started a personal modernization project to address some of the platform's technical debt. So far, I've completed the following work: - Replaced the legacy GWT WebAdmin with a React-based frontend. - Completely removed the GWT frontend and the GWT-RPC communication layer. - Migrated client-server communication to REST APIs. - Upgraded the platform to Jakarta EE 11, WildFly 40, Java 21, and PostgreSQL 16. - Applied numerous security and dependency updates. The project is still being validated, but most of the functionality is already working. I would like to know whether there is still active interest in modernizing oVirt Engine. If so, I'd be happy to discuss the project, share my experience, and explore whether any part of this work could be useful for the community. Please note that I'm not a professional software developer—I'm an infrastructure engineer—and I'm communicating in English using a translator. I appreciate your understanding. Thank you for your time, and I look forward to hearing from you. Best regards, Jeong Haneul [image: image.png][image: image.png][image: image.png][image: image.png]

4 4

Question for self hosted engine license
by 장진한 30 Oct '26

30 Oct '26

Hi, This is Colin from Dahami Communications. We are currently utilizing virtualization systems. I have a few questions regarding oVirt. We are planning to deploy a Self-Hosted Engine environment. Does this setup require any separate licenses or additional costs to use? Thank you in advance for your help. Best regards, Colin 장진한 책임 / 연구개발부문 (주)다하미커뮤니케이션즈 T 02-593-4174 (ext. 417) <tel:+82-2-593-4174> | F 02-593-4175 M 010-3318-3497 <tel:+82-10-3318-3497> | E colin(a)dahami.com <mailto:colin@dahami.com> 04560 서울특별시 중구 마른내로 140, 5층 (쌍림동, 인쇄정보센터)

2 1

Still running oVirt after 7 years
by rak kim 30 Oct '26

30 Oct '26

Hello to all the oVirt veterans here, I'm a virtualization engineer who has run oVirt as my main platform for about seven years, mostly Oracle's build of it, OLVM. I've also worked with VMware, OpenStack, and Proxmox. Of those four, honestly, VMware seems to be the best 😅. It rarely goes down, and strangely, even on the same hardware it seems to hit far fewer faults (just my own experience). OpenStack is great for development by many people and for scaling out on a large scale, but it can be complex and hard to operate. The UI is limited too, so in operations I mostly use the CLI. Proxmox has a good API and a modular design, but maybe it's just habit: it doesn't feel as convenient as oVirt, where I can check logs and troubleshoot from one place, the Engine. Among them, I've always found oVirt stable and easy to use. I often thought it would be more than enough for small companies. But it's a bit sad that it hasn't grown as much as I expected. I was personally very sad to see RHV discontinued. Oracle still maintains it as OLVM, and well, I really hope they keep doing so. Red Hat's OpenStack offering is also moving onto OpenShift. Maybe it's because the software industry has shifted toward cloud-native (containers and Kubernetes)? OS and virtualization upgrade cycles also seem to be getting shorter these days. Still, oVirt was the platform I started my career on, so it means a lot to me. I'm still running oVirt today, and my company is adopting it more and more. These days I also operate a private cloud based on openstack-helm. In the past my work was mostly incident response and analysis, but now I'd like to give something back and contribute to oVirt, even in a small way. What do you think could help oVirt grow and thrive again? I'd love to hear your thoughts. It's been a while since I visited the community, so I just wanted to write a few lines. I hope to keep using oVirt for a long time. Cheers to everyone keeping it going!

1 0

Call for participation: Virtualization and Cloud infrastructure Room at FOSDEM 2027
by Piotr Kliczewski 26 Oct '26

26 Oct '26

We are excited to announce that the call for proposals is now open for the Virtualization and Cloud infrastructure devroom at the upcoming FOSDEM 2027, to be hosted on January 30th (Saturday). This devroom is a collaborative effort, and is organized by dedicated folks from projects such as OpenStack, Xen Project, KubeVirt, QEMU, KVM, and Foreman. We invite everyone involved in these fields to submit your proposals by November 23rd. About the Devroom The Virtualization & IaaS devroom will feature session topics such as open source hypervisors or virtual machine managers such as Xen Project, KVM, bhyve and VirtualBox as well as Infrastructure-as-a-Service projects such as KubeVirt, Apache CloudStack, OpenStack, 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 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: 23rd of November Acceptance notifications: 1st of December Final schedule announcement: 7th of December Devroom: 30th of January (Saturday) Submit Your Proposal During submission [1] please make sure to select Virtualization and Cloud infrastructure from the Track list. Please 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 be recorded 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, Piotr Kliczewski and Tal Nisan In the Submission notes field, please also confirm that if your talk is accepted, you will be able to attend FOSDEM and deliver your presentation. We will not consider proposals from prospective speakers who are unsure whether they will be able to secure funds for travel and lodging to attend FOSDEM. (Sadly, we are not able to offer travel funding for prospective speakers.) Code of Conduct Following the release of the updated code of conduct for FOSDEM[2], 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. 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://fosdem.org/submit [2] https://fosdem.org/2027/practical/conduct/ <https://fosdem.org/2026/practical/conduct/>

1 0

[oVirt 4.5.7] CCD/CCX and L3 cache topology awareness for AMD EPYC Genoa guests
by Srini Balaji 08 Oct '26

08 Oct '26

Subject: [oVirt 4.5.7] CCD/CCX and L3 cache topology awareness for AMD EPYC Genoa guests Hello oVirt community, First, thank you to everyone who contributed to the oVirt 4.5.7 release. It is great to see the project moving forward, and the addition of the AMD EPYC Genoa CPU type in cluster level 4.8 is very welcome. I am designing an oVirt-based virtualization platform on Dell PowerEdge servers with AMD EPYC Genoa ( 9654 series) processors. On Genoa, each CCD contains one CCX of up to 8 cores that share a 32 MB L3 cache, and a socket can have up to 12 CCDs. For latency-sensitive workloads, keeping a VM's vCPUs within one CCD, and making the guest aware of which vCPUs share an L3 cache, makes a measurable difference to performance. I would like to understand what oVirt 4.5.7 supports out of the box in this area: 1. CPU type scope: Does the new EPYC Genoa CPU type only expose the CPU model and CPUID feature flags to the guest, or does it also influence the virtual CPU topology (sockets/dies/cores/threads) and cache topology the guest sees? 2. Die and cache topology in the domain XML: Does the engine/VDSM generate a libvirt <topology> with the 'dies' attribute, or a <cache> element (passthrough or emulated L3), so that the guest can see CCD/CCX boundaries? If so, which VM types or settings enable it (for example, the High Performance VM type or Pass-Through Host CPU)? 3. Guest view of L3 sharing: When vCPUs are pinned to the cores of a single CCD, should the guest report correct L3 sharing (for example in 'lscpu -C' or /sys/devices/system/cpu/cpu*/cache/index3/shared_cpu_list), or will it typically present one L3 shared across all vCPUs? 4. Scheduling and pinning: Do the CPU pinning policies (Dedicated, Isolate Threads, Resize and Pin NUMA) take CCD/CCX boundaries into account when choosing host cores? Is there support for hosts configured with the BIOS option 'L3 as NUMA' (LLC as NUMA node), where each CCX appears as its own NUMA node? 5. Roadmap: If CCD/L3-aware topology is not available today, is it on the roadmap for a future 4.5.x or later release? Is there an existing GitHub issue or RFE I can follow or contribute details to? In the meantime, is a VDSM hook that adds the dies/cache elements to the domain XML the recommended workaround, or is there a better approach? I am happy to test any builds or patches on Genoa hardware and share the results (lscpu output, libvirt XML, and benchmark numbers) with the community. Thank you for your time and guidance. Best regards, Srini

1 0

Re: Future oVirt versions
by Daniel de Morais Gurgel 29 Sep '26

29 Sep '26

An important feature would be to allow the migration of virtual machines between different data centers.

1 0

Yum repositories for 4.5.7 hosted engine VM
by Devin A. Bougie 13 Aug '26

13 Aug '26

Hello, What yum repositories should be enabled on a 4.5.7 self-hosted engine VM running AlmaLinux 9.8? We successfully updated our cluster (hosted engine VM And all hosts), but are getting the following conflicts when trying to update the VM itself. Many thanks, Devin ——— [root@lnxvirt-engine ~]# dnf repolist --enabled repo id repo name appstream AlmaLinux 9 - AppStream baseos AlmaLinux 9 - BaseOS centos-ceph-pacific CentOS-9-stream - Ceph Pacific centos-gluster10 CentOS-9-stream - Gluster 10 centos-nfv-openvswitch CentOS Stream 9 - NFV OpenvSwitch centos-openstack-yoga CentOS-9 - OpenStack yoga centos-opstools CentOS Stream 9 - OpsTools - collectd centos-ovirt45 CentOS Stream 9 - oVirt 4.5 centos-rabbitmq-38 CentOS-9 - RabbitMQ 38 crb AlmaLinux 9 - CRB extras AlmaLinux 9 - Extras ovirt-45-upstream oVirt upstream for CentOS Stream 9 - oVirt 4.5 resilientstorage AlmaLinux 9 - ResilientStorage [root@lnxvirt-engine ~]# dnf update CentOS-9-stream - Ceph Pacific 1.1 MB/s | 581 kB 00:00 CentOS-9-stream - Gluster 10 17 kB/s | 56 kB 00:03 CentOS-9 - RabbitMQ 38 760 kB/s | 123 kB 00:00 CentOS Stream 9 - NFV OpenvSwitch 3.1 MB/s | 485 kB 00:00 CentOS-9 - OpenStack yoga 663 kB/s | 3.1 MB 00:04 CentOS Stream 9 - OpsTools - collectd 12 kB/s | 51 kB 00:04 CentOS Stream 9 - oVirt 4.5 1.3 MB/s | 1.3 MB 00:00 oVirt upstream for CentOS Stream 9 - oVirt 4.5 3.2 kB/s | 11 kB 00:03 AlmaLinux 9 - AppStream 51 MB/s | 20 MB 00:00 AlmaLinux 9 - BaseOS 60 MB/s | 27 MB 00:00 AlmaLinux 9 - CRB 22 MB/s | 4.9 MB 00:00 AlmaLinux 9 - Extras 220 kB/s | 22 kB 00:00 AlmaLinux 9 - ResilientStorage 1.3 MB/s | 164 kB 00:00 Error: Problem 1: package usbguard-1.1.4-2.el9.x86_64 from @System requires libprotobuf.so.25()(64bit), but none of the providers can be installed - cannot install both protobuf-3.19.0-2.el9s.x86_64 from centos-ceph-pacific and protobuf-3.14.0-17.el9_7.x86_64 from @System - cannot install both protobuf-3.19.0-2.el9s.x86_64 from centos-ceph-pacific and protobuf-3.14.0-6.el9s.x86_64 from centos-ceph-pacific - cannot install both protobuf-3.14.0-17.el9_7.x86_64 from appstream and protobuf-3.19.0-2.el9s.x86_64 from centos-ceph-pacific - cannot install the best update candidate for package usbguard-1.1.4-2.el9.x86_64 - cannot install the best update candidate for package protobuf-3.14.0-17.el9_7.x86_64 Problem 2: 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 3: 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 4: 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) ———

3 7