- Devel - oVirt List Archives

oVirt GitHub Users Cleanup
by Jean-Louis Dupond 18 Jun '26

18 Jun '26

Hi All, I send this email to inform everyone that we will do a big cleanup of users on the oVirt Org on GitHub. Now plenty of inactive developers still have various permissions, and in order to make this more safe, we are going to do a cleanup round. All users that have not contributed anything since 6 months will be removed from the oVirt Organisation on GitHub in the next month. If there is any other reason you still need permissions, please feel free to respond directly to me. This doesn't mean you cannot contribute to oVirt anymore in the future! You can still open PR's/Issues if you want to contribute! Thanks everyone! Jean-Louis

2 1

[RFC] Kerberos/GSSAPI authentication on oVirt 4.5.x without Apache — feasibility question + Java 21 JPMS bug in UnboundID SDK
by Eden Martinez 04 Mar '26

04 Mar '26

Hello oVirt developers, My name is Eden, I am a Senior Systems Administrator at Semtech managing oVirt 4.5.x infrastructure across multiple sites. I am writing to the community with two related questions regarding Kerberos authentication, and to share a bug we have found and a proposed fix. 1. IS KERBEROS AUTHENTICATION POSSIBLE WITHOUT APACHE OR KEYCLOAK? All existing documentation for Kerberos SSO on oVirt (both the AAA-LDAP extension path and the Red Hat Virtualization Administration Guide) requires Apache with mod_auth_gssapi as an intermediary to perform SPNEGO negotiation and pass the authenticated principal to the engine via X-Remote-User headers. We would like to understand whether there is any supported or planned path to perform Kerberos/GSSAPI authentication directly within the oVirt engine (WildFly/JBoss), without relying on either: - Apache + mod_auth_gssapi + ovirt-engine-extension-aaa-misc (legacy path) - Keycloak with Kerberos User Federation (4.5.1+ path) Specifically, the AAA-LDAP extension already supports GSSAPI binds to LDAP via the UnboundID SDK (pool.default.auth.type = gssapi). Could the engine's own SSO negotiate endpoint be extended to handle SPNEGO directly via the JAAS/GSS-API stack running inside WildFly, eliminating the Apache dependency entirely? We understand this may not be a currently supported configuration. If so, we would appreciate confirmation so we can plan accordingly. 2. JAVA 21 / JPMS BUG: GSSAPI LDAP BIND FAILURE IN UNBOUNDID SDK ON WILDFLY While working on Kerberos integration for our oVirt 4.5.x environment running on CentOS Stream 10 with OpenJDK 21, we identified a critical bug that prevents GSSAPI LDAP binds from working when the AAA-LDAP extension runs inside WildFly. Root cause: WildFly's PicketBox security framework replaces Java's standard JAAS Configuration (sun.security.provider.ConfigFile) with its own implementation via Configuration.setConfiguration(). PicketBox's Configuration cannot load com.sun.security.auth.module.Krb5LoginModule from the jdk.security.auth JPMS module, because PicketBox's JBoss module does not declare a dependency on jdk.security.auth. The UnboundID SDK's GSSAPIBindRequest.process() method calls Configuration.getConfiguration().refresh() and then uses the two-argument LoginContext constructor, which internally calls Configuration.getConfiguration() again — both of which return PicketBox's broken implementation. The result is: LoginException("No LoginModules configured for <jaasClientName>") We verified that the standard ConfigFile implementation correctly parses the JAAS config and finds Krb5LoginModule when invoked outside of WildFly on the same JVM. Proposed fix: Modify GSSAPIBindRequest.process() to use the four-argument LoginContext constructor with an explicit Configuration object created via Configuration.getInstance("JavaLoginConfig", new URIParameter(configURI)). This completely bypasses the global Configuration.getConfiguration() call and uses the standard Java JAAS file parser directly. The fallback else branch preserves the original two-argument constructor behavior for non-WildFly environments. We have a full technical write-up with bytecode evidence, the exact proposed patch, and a list of alternative approaches we tried and eliminated. We are happy to share the complete document, submit a pull request to ovirt-engine-extension-aaa-ldap, or file a GitHub issue — whichever is preferred. This also affects the UnboundID LDAP SDK upstream (Ping Identity), and we plan to report it there as well. Affected versions: - oVirt Engine 4.5.x on CentOS Stream 10 - UnboundID LDAP SDK 7.0.3 (bundled with ovirt-engine-extension-aaa-ldap 1.5.0) - OpenJDK 21.0.6 (jdk-21.0.6+7-LTS) - WildFly 26.x with PicketBox legacy security subsystem Thank you for your time. We are happy to contribute testing, patches, or further analysis. Best regards, Eden Senior Systems Administrator, Semtech Eden Martinez :: Senior Staff Engineer, Linux Admin [cid:image001.png@01DCAB0A.ED1B6350] SEMTECH CORPORATION IT Helpdesk +1 (855) 271 6352 :: Office +52 (449) 918 2823 Av. Monte Blanco 612, CP 20115, Aguascalientes, Ags. [cid:image002.gif@01DCAB0A.ED1B6350]<https://www.linkedin.com/company/semtech> [cid:image003.gif@01DCAB0A.ED1B6350]<https://twitter.com/SemtechCorp> [cid:image004.gif@01DCAB0A.ED1B6350]<https://blog.semtech.com/> www.semtech.com<https://www.semtech.com/> :: Subscribe to our Newsletter<https://www.semtech.com/subscribe> To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal.

2 1

major release wish list
by Diggy Mc 03 Feb '26

03 Feb '26

My wish list is short and simple for the next major release of oVirt: * OS templates for RHEL 9 & 10, FreeBSD 14 & 15, Ubuntu 24.04 LTS, Windows Server 2022, and Debian 12 & 13. * Deprecated "export domain" remains an option. I will need it to migrate VMs from existing legacy oVirt environment to brand new oVirt environment. * Support to run latest OKD.io (Kubernetes) platform as VMs. Anything you can do to help is much appreciated. Thanks.

7 10

is this for a bug report?
by lejeczek 14 Oct '25

14 Oct '25

Hi guys. It might Centos's repo/packages related - I'm not sure how this worsk - so, where to send/file a bug report with issue like this: ... [ INFO ] ok: [localhost] [ INFO ] TASK [ovirt.ovirt.engine_setup : Install oVirt Engine package] [ ERROR ] fatal: [localhost -> 192.168.1.90]: FAILED! => {"changed": false, "msg": "Failed to download metadata for repo 'centos-ceph-pacific': Cannot prepare internal mirrorlist: Curl error (6): Couldn't resolve host name for http://mirrorlist.centos.org/?release=8-stream&arch=x86_64&repo=storage-cep… <http://mirrorlist.centos.org/?release=8-stream&arch=x86_64&repo=storage-cep…> [Could not resolve host: mirrorlist.centos.org <http://mirrorlist.centos.org>]", "rc": 1, "results": []} [ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : Sync on engine machine] ... thanks, L.

1 0

Re: Engine planning guide has the following - is this still correct.
by Sandro Bonazzola 18 Mar '25

18 Mar '25

ppc64le support was contributed by IBM https://mirror.stream.centos.org/SIGs/9-stream/virt/ppc64le/kvm-common/ but the latest qemu-kvm there is 7.0 from 2022. ARM packages for ovirt are still being built in COPR and in CentOS Virtualization SIG, not sure if someone ever gave them a try -- Sandro Bonazzola

1 0

Engine planning guide has the following - is this still correct.
by Geoff O'Callaghan 18 Mar '25

18 Mar '25

Hi team, The planning guide has: Enterprise Linux 9 doesn’t support virtualization for ppc64le: CentOS Virtualization SIG<https://wiki.centos.org/SpecialInterestGroup/Virtualization> is working on re-introducing virtualization support but it’s not ready yet. The oVirt project also provides packages for the 64-bit ARM architecture (ARM 64) but only as a Technology Preview. Ie. Do we / are we going to support ppc ? Unlikely, or ARM - quite possible ? Thanks Geoff

1 0

Problems installing ovirt-hosted-engine-setup
by Harald Schwier 07 Oct '24

07 Oct '24

Hello, >08107301-ovirt-engine/ 2024-Oct-04 07:41:25 -- Directory >08107317-ovirt-engine/ 2024-Oct-04 08:02:14 -- Directory >08107446-ovirt-engine/ 2024-Oct-04 08:43:45 -- Directory since the changes made three days ago,it is no longer possible to install ovirt-hosted-engine-setup with Rocky 9: # dnf install ovirt-hosted-engine-setup Last metadata expiration check: 0:21:29 ago on Mon 07 Oct 2024 03:20:46 PM CEST. Error: Problem: package ovirt-hosted-engine-setup-2.7.2-0.0.master.20231129144914.gitdda363b.el9.noarch from copr:copr.fedorainfracloud.org:ovirt:ovirt-master-snapshot requires ovirt-hosted-engine-ha >= 2.4, but none of the providers can be installed - package ovirt-hosted-engine-ha-2.5.0-0.0.master.20211124111936.el9.noarch from ovirt-master-centos-stream-ovirt45-testing requires vdsm >= 4.40.0, but none of the providers can be installed - package ovirt-hosted-engine-ha-2.5.0-1.el9.noarch from ovirt-master-centos-stream-ovirt45-testing requires vdsm >= 4.40.0, but none of the providers can be installed - package ovirt-hosted-engine-ha-2.5.1-1.el9.noarch from ovirt-master-centos-stream-ovirt45-testing requires vdsm >= 4.40.0, but none of the providers can be installed - package ovirt-hosted-engine-ha-2.5.2-0.0.master.20231129140104.20231129140102.git146da71.el9.noarch from copr:copr.fedorainfracloud.org:ovirt:ovirt-master-snapshot requires vdsm >= 4.40.0, but none of the providers can be installed - package vdsm-4.50.0.10-1.el9.x86_64 from ovirt-master-centos-stream-ovirt45-testing requires libvirt-lock-sanlock, but none of the providers can be installed - package vdsm-4.50.0.11-1.el9.x86_64 from ovirt-master-centos-stream-ovirt45-testing requires libvirt-lock-sanlock, but none of the providers can be installed - package vdsm-4.50.0.12-1.el9.x86_64 from ovirt-master-centos-stream-ovirt45-testing requires libvirt-lock-sanlock, but none of the providers can be installed - package vdsm-4.50.0.13-1.el9.x86_64 from ovirt-master-centos-stream-ovirt45-testing requires libvirt-lock-sanlock, but none of the providers can be installed - package vdsm-4.50.0.6-1.el9.x86_64 from ovirt-master-centos-stream-ovirt45-testing requires libvirt-lock-sanlock, but none of the providers can be installed - package vdsm-4.50.0.7-1.el9.x86_64 from ovirt-master-centos-stream-ovirt45-testing requires libvirt-lock-sanlock, but none of the providers can be installed - package vdsm-4.50.0.8-1.el9.x86_64 from ovirt-master-centos-stream-ovirt45-testing requires libvirt-lock-sanlock, but none of the providers can be installed - package vdsm-4.50.1.1-1.el9.x86_64 from ovirt-master-centos-stream-ovirt45-testing requires libvirt-lock-sanlock, but none of the providers can be installed - package vdsm-4.50.1.2-1.el9.x86_64 from ovirt-master-centos-stream-ovirt45-testing requires libvirt-lock-sanlock, but none of the providers can be installed - package vdsm-4.50.1.3-1.el9.x86_64 from ovirt-master-centos-stream-ovirt45-testing requires libvirt-lock-sanlock, but none of the providers can be installed - package vdsm-4.50.1.4-1.el9.x86_64 from ovirt-master-centos-stream-ovirt45-testing requires libvirt-lock-sanlock, but none of the providers can be installed - package vdsm-4.50.2.1-1.el9.x86_64 from ovirt-master-centos-stream-ovirt45-testing requires libvirt-lock-sanlock, but none of the providers can be installed - package vdsm-4.50.2.2-1.el9.x86_64 from ovirt-master-centos-stream-ovirt45-testing requires libvirt-lock-sanlock, but none of the providers can be installed - package vdsm-4.50.3-1.el9.x86_64 from ovirt-master-centos-stream-ovirt45-testing requires libvirt-lock-sanlock, but none of the providers can be installed - package vdsm-4.50.3.1-1.el9.x86_64 from ovirt-master-centos-stream-ovirt45-testing requires libvirt-lock-sanlock, but none of the providers can be installed - package vdsm-4.50.3.2-1.git545b51151.el9.x86_64 from ovirt-master-centos-stream-ovirt45-testing requires libvirt-lock-sanlock, but none of the providers can be installed - package vdsm-4.50.3.4-1.el9.x86_64 from ovirt-master-centos-stream-ovirt45-testing requires libvirt-lock-sanlock, but none of the providers can be installed - package vdsm-4.50.5.1-1.el9.x86_64 from ovirt-master-centos-stream-ovirt45-testing requires libvirt-lock-sanlock, but none of the providers can be installed - package vdsm-4.50.6-8.git4d11cae0b.el9.x86_64 from copr:copr.fedorainfracloud.org:ovirt:ovirt-master-snapshot requires libvirt-lock-sanlock, but none of the providers can be installed - cannot install the best candidate for the job - nothing provides libvirt-libs = 10.0.0-6.6.el9_4 needed by libvirt-daemon-plugin-sanlock-10.0.0-6.6.el9_4.x86_64 from crb The same installation worked four days ago. Kind regards Harald Schwier

1 0

Re: Yuriy about NVMe over fabrics for oVirt
by Nir Soffer 12 Aug '24

12 Aug '24

On Thu, Nov 2, 2023 at 4:40 PM Yuriy <ykhokhlov(a)gmail.com> wrote: > Hi Nir! > > This is Yuriy. > We agreed to continue the subject via email. > So the options are: 1. Using Managed Block Storage (cinderlib) with a driver that supports NVMe/TCP. Lastest oVirt has the needed changes to configure this. Benny and I tested with Lightbits[1] driver in a virtualized environment. This is basically a POC that may work for you or not, or require more work that you will have to do yourself since not much development is happening now in oVirt. 2. Using the devices via multipath Legacy storage domains are based on multipath. It may be possible to use multipath on top of NVMe devices, and in this case they look like a normal LUN so you can create a storage domain from such devices. oVirt will not handle connections for you, and all the devices must be connected to all nodes at the same time, just like FC/iSCSI LUNs. You will likely not get the performance benefit of NVMe/TCP. 3. Using host devices If what you need is using some devices (which happen to be connected via be NVMe/TCP), maybe you can attach them to a VM directly (using host devices). This gives the best possible performance but no features (snapshots, backup, live migration, live storage migration, etc.) [1] https://www.lightbitslabs.com/ Nir

2 3

Reminder: CentOS Stream 8 is now EOL
by Sandro Bonazzola 03 Jun '24

03 Jun '24

Hi, just a reminder that CentOS Stream 8 reached its end of life at the end of last month on Friday, May 31, 2024. As it has been announced by CentOS project[1], all the CentOS Stream 8 repositories are going to be archived at vault.centos.org . Who didn't update yet to CentOS Stream 9 will probably hit several errors related to this archiving: you'll need to manually adjust the repository url to point to the new location at vault.centos.org. The archiving is going to happen today [2] with the decommissioning of the nodes used by the CentOS Community Build System used for oVirt builds for Stream 8 within the CentOS Virtualization SIG. At this point, the recommendation is to upgrade to CentOS Stream 9 (or derived) as soon as practical. For those who are pushing changes to the oVirt project, please note GitHub actions may start to fail on CentOS Stream 8 (and with that, the builds for oVirt Node and oVirt Appliance). It's up to you to decide if you want to change the config there to use a different el8 distribution for running the tests or just turn off el8 and rely only on CentOS Stream 9 tests. [1] https://lists.centos.org/hyperkitty/list/announce@lists.centos.org/thread/D… [2] https://lists.centos.org/hyperkitty/list/devel@lists.centos.org/thread/P3HD… -- Sandro Bonazzola

1 0

Re: storage domains (obsolete)
by Wild Star 18 May '24

18 May '24

I know they have been deprecated and can be replaced with Data, but we still use the ISO and Export domain types and like having them. Cheers! ... Wild

2 1