- Users - oVirt List Archives

"400 Bad request" error logging in
by Dan O'Brien 19 Nov '25

19 Nov '25

This is even more mysterious now that I've discovered it's only a problem for ME and only when I'm logged in to Chrome. Safari and Edge work, and so does a Chrome private browsing window. Nonetheless, there seems to be a fix on the server side, if I'm correct. After entering credentials on the logon screen (internalsso), I get a "400 Bad Request" error in the browser and I'm seeing these errors in /var/log/httpd/error_log: [Wed Nov 19 14:37:04.988719 2025] [proxy_ajp:error] [pid 2364:tid 2392] AH03229: ajp_msg_append_cvt_string(): BufferOverflowException 4 8159 I found this post on the list https://lists.ovirt.org/archives/list/users@ovirt.org/thread/K4MBGS3ZD4LK6S… and these in the Red Hat knowledge base (must log in to view) https://access.redhat.com/solutions/1525873 https://access.redhat.com/solutions/732343 (for JBoss 6) https://access.redhat.com/solutions/6166212 (For JBoss 7, which I think oVirt 4.5 uses) The solution is to change a couple of settings in httpd.conf (or in httpd.conf.d): LimitRequestFieldsize 65536 ProxyIOBufferSize 65536 There's a corresponding setting that needs to be changed in JBoss/Wildfly. I think the standalone.xml file referred to in the KB articles is in /usr/share/ovirt-engine-wildfly/standalone/configuration Can someone confirm? Also, is oVirt 4.5 (4.5.7-0.master.20251029141850.git6e58a03353.el9, specifically) using 6 or 7? Running ./jboss-cli.sh from /usr/share/ovirt-engine-wildfly/bin fails with the error Failed to connect to the controller: The controller is not available at localhost:9990: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+http://localhost:9990. The connection failed: WFLYPRT0053: Could not connect to remote+http://localhost:9990. The connection failed: Connection refused Is it listening on another port? I tried ./jboss-cli.sh --version but it wants to be connected

1 0

certs expired, now engine won't start
by Michael Thomas 18 Nov '25

18 Nov '25

I seem to have gotten myself into a bit of a pickle. My ovirt host certs (4-node 4.4.1 cluster) expired recently and I didn't notice until one of my hosts got fenced on Friday. I was finally able to get it back online by rebooting, telling the ovirt-engine the host had been rebooted (so that it didn't think VMs were running on it), and then going into maintenance mode and 'enroll certificates' to renew the certs. This worked with the second host as well. But I was unable to put the third host into maintenance mode because the engine claimed "Another power management action is already in progress". Sure enough, the task list showed the engine trying to take action against this host. It was stuck in that state for over an hour, so I finally poked the ovirt-engine database directly to fail these tasks: psql engine -c "UPDATE job SET status = 'FAILED', end_time = NOW() WHERE status NOT IN ('FINISHED', 'FAILED');" psql engine -c "UPDATE step SET status = 'FAILED', end_time = NOW() WHERE status NOT IN ('FINISHED', 'FAILED');" This got the tasks to clear, but the engine UI still claimed that the stuck host still had "Another power management action is already in progress". Then I made the fatal mistake of rebooting the ovirt-engine (which was still running on the fourth host with expired certs). Now my engine won't start, even when I try to start it on one of the host that had certs renewed. The libvirt logs indicate that it's because the vnc cert is expired: qemu-kvm: -object tls-creds-x509,id=vnc-tls-creds0,dir=/etc/pki/vdsm/libvirt-vnc,endpoint=server,verify-peer=no: The server certificate /etc/pki/vdsm/libvirt-vnc/server-cert.pem has expired Since I don't care about vnc access to the engine, is there a way to get the engine running again without vnc? Alternately, is there a way that I can manually get some of the more critical VMs running without an engine running? FWIW, I tried searching the list archives, but I get a 500 server error when trying to go to lists.ovirt.org. --Mike

2 1

oVirt and iSCSI storage
by Dan O'Brien 17 Nov '25

17 Nov '25

TL;DR: I’d like to better understand iSCSI “connections” versus oVirt iSCSI multipath bonds. Also how oVirt caches iSCSI connection information and credentials. I’m standing up a new cluster that will replace an aging cluster running oVirt 4.3 on CentOS 7 hosts and GlusteFS storage. I’ve cleared most of the milestones I need to proceed with migrating the VMs, but I’m struggling a bit with the interaction of oVirt’s networking and the iSCSI storage for the new cluster. The new cluster is Rocky 9.6 hosts, and oVirt installed from the master snapshot on 10/31/2025. My storage for the new cluster is using the Ceph iSCSI gateway (2 hosts, 1 iSCSI target, 1 IP from each assigned as portal). I have a dedicated VLAN for iSCSI traffic (VLAN 42: 192.168.42.0/24). I removed one of the hosts from the old cluster (Dell PowerEdge R620) and have used it to seed the new cluster with the self-hosted engine. I have 2 Ceph hosts running the iSCSI gateway on VLAN 42 assigned IPs .85 and .88. During the deployment of the hosted engine, I’m prompted for the storage and I used 192.168.42.88 as the iSCSI portal and logged in to the target and the deployment succeeded. I had a LUN on the iSCSI target for the hosted engine and the associated storage domain. For the deployment of the hosted engine, I had one NIC set up and assigned a static IP on our internal network (access port, no VLAN tagging). The ovirtmgmt logical network gets assigned to this and the hosted engine coexists happily with the host sharing the NIC in the same subnet. Before deployment, the host was set up with a bond of 2x10G ethernet ports in a LAG and a VLAN interface for VLAN 42. If I look at the host Network Interfaces after deployment, I can see the existing bond (bond0). The VLAN interface I created before deployment (bond0.42) is listed under Logical Networks, but is flagged as Unmanaged. Once in the UI, I created 2 additional Storage Domains (Data): one for ISOs and one for VMs using additional LUNs (backed by Ceph RBD images). The UI seems to have re-used the iSCSI connection set up for the hosted engine. I could see the LUNs I created for and was able to assign the LUNs to the storage domains (1x512Gb RBD for ISOs and 2x512Gb RBD for the storage domain). All of this is great, BUT I’m only using one of the iSCSI gateways. One option I have is to set up iSCSI multipathing in the datacenter. This doesn’t seem to be possible for two reasons: My storage network is being accessed by the unmanaged logical network, AND I need an ADDITIONAL VLAN using a different subnet to set up another logical network for the iSCSI multipath bond. This is a bit of a headache, but I think it’s doable after I add another host, and migrate the hosted engine so I can remove the unmanaged VLAN 42 from the bond and replace it with a managed logical network tagged with VLAN 42 and assigned an appropriate IP address. HOWEVER – I noticed on the storage domain, there’s a CONNECTIONS button. This shows a panel with an “Attached” connection to the iSCSI target and the portal address I specified during the hosted engine setup. After putting the ISOs storage domain in maintenance, I could add another connection with the second portal of the target (I’m not sure this actually did anything). When I tried to do this for the storage domain, I got an error that a connection already existed. Attempting discovery entering the IP address of one of the portals and the CHAP username/password doesn’t seem to work; I keep getting authentication failures even though I’m pretty sure I’m using the right credentials. So my questions: - What’s the difference between multiple “paths” and the multipathing set up in oVirt? - What information about the iSCSI connections is oVirt storing and how is it using it when you set up later storage domains? - Are multiple “paths” in the storage domain equivalent to the multipath bonds? I’d like to use the existing portals in my iSCSI VLAN and not have to set up another VLAN (which is not terrible, just inconvenient). - Is there a way of manipulating the iSCSI connection information after-the-fact? There's a warning in the docs that adding paths isn't supported, but it seems to only refer to the UI. Can it be done with the REST API or Ansible? Sorry for the long read. I've been using oVirt since I started at my present job and it's been solid. I appreciate the work you're doing keeping this project going. I'm looking forward to having a cluster with the latest software and retiring GlusterFS.

3 3

Reclaim Storage OLVM
by Đỗ Tài 10 Nov '25

10 Nov '25

I have a case with a customer. They are using the KVM/OLVM system because they do not enable discard after delete, so when deleting VM, they do not send the umap command to SAN Storage, so over time there is a difference between OLVM and SAN metadata. Specifically, on OLVM, it reports 8TB free but on SAN, it only reports 3TB free. SAN cannot reclaim 5TB free of OLVM because it is blocking under SAN because SAN understands that those blocks are in use. The first thing I did was enable discard after delete for the storage domain, but now I want to free up 5TB on OLVM so that SAN can reclaim that capacity, how do I do that?

1 0

Re: [ovirt-announce]Re: oVirt - project update
by eson＠inux.cz 03 Nov '25

03 Nov '25

totally agree, we also do love it! rest of the year we ill put capacity to enhanced testing and freedback to community ty Jean-Louis and all the community members On 2025-09-23 11:05, wdh(a)dds.nl wrote: > Love it! > _______________________________________________ > Announce mailing list --announce(a)ovirt.org > To unsubscribe send an email toannounce-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/announce@ovirt.org/message/L…

1 0

Re: Veeam - Move data over other network than ovirtmgmt
by Berat Aksoy 30 Oct '25

30 Oct '25

Good solution. We are testing Vinchin Backup & Recovery and it works perfect. I think it could be a good alternative to Veeam.

2 1

Call for participation: Virtualization and Cloud infrastructure Room at FOSDEM 2026
by Piotr Kliczewski 28 Oct '25

28 Oct '25

We are excited to announce that the call for proposals is now open for the Virtualization and Cloud infrastructure devroom at the upcoming FOSDEM 2026, to be hosted on 31st of January. 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 5th December 2025. 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: 5th December 2025 Acceptance notifications: 10th December 2025 Final schedule announcement: 15th of December 2025 Devroom: 31st of January 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/2026/practical/conduct/

1 0

URGENT : VM Manager Down, error sanlock no ids file
by wodel youchi 27 Oct '25

27 Oct '25

Hi, I've an ovirt HCI deployment, and after a certificate expiration, and some bad cli commands, the VM Manager is down and won't start. The problem is with sanlock, the ids file on dom_md of the hosted storage does not exist anymore. sanlock open error -2 /rhev/data-center/mnt/glusterSD/node10.example.com: _engine/5146d5c4-fb3a-4937-9107-fe020146c2ed/dom_md/ids Is there a way to recreate this file? Regards.

1 0

Installing oVirt on Oracle Linux 9
by Igor Filipovic 22 Oct '25

22 Oct '25

Hi, In case anyone's interested: Today I successfully deployed a new oVirt 4.5.7 on Oracle Linux 9.6 hosts. The bottom line: deployment went fine on a minimal OL9.6 install. In addition to the ovirt/ovirt-master-snapshot repository, you must also enable the ol9_codeready_builder repository — it's required to install libvirt-lock-sanlock. After that SHE installation went smoothly. OS Version: RHEL - 9.6 - 1.0.9.el9 OS Description: Oracle Linux Server 9.6 Kernel Version: 6.12.0 - 104.43.4.2.el9uek.x86_64 KVM Version: 9.1.0 - 15.el9_6.9 LIBVIRT Version: libvirt-10.10.0-7.7.0.1.el9_6 VDSM Version: vdsm-4.50.6-202510211310.git33e8c2c63.el9

1 0

Hosted engine deployment failing on step Check OVF_STORE volume status
by igor.filipovic＠power.in.rs 21 Oct '25

21 Oct '25

Hi, I have tried several different physical hosts and several different OS releases (Alma 9.6, Rocky 9.6, CentOS 9 stream) to deploy hosted engine. My scenario is physical hosts with shared FC storage. Deployment always fails at step "Check OVF_STORE volume status" ... Any ideas ? BR, Igor Details in log: # cat /var/log/ovirt-hosted-engine-setup/ovirt-hosted-engine-setup-20251019183708-eo1ffp.log | grep ERROR ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62940 2025-10-19 19:15:36,379+0200 ERROR otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:113 {'changed': True, 'stdout': '{\n "apparentsize": "134217728",\n "capacity": "134217728",\n "children": [],\n "ctime": "1760893778",\n "description": "{\\"DiskAlias\\":\\"OVF_STORE\\",\\"DiskDescription\\":\\"OVF_STORE\\"}",\n "disktype": "OVFS",\n "domain": "08d9d3f1-86fe-4159-95a8-bd686f44716d",\n "format": "RAW",\n "generation": 0,\n "image": "0d4c388c-37a8-4161-9e5b-874af83c03c7",\n "lease": {\n "offset": 106954752,\n "owners": [],\n "path": "/dev/08d9d3f1-86fe-4159-95a8-bd686f44716d/leases",\n "version": null\n },\n "legality": "LEGAL",\n "mtime": "0",\n "parent": "00000000-0000-0000-0000-000000000000",\n "pool": "",\n "sequence": 1,\n "status": "OK",\n "truesize": "134217728",\n "type": "PREALLOCATED",\n "uuid": "1c41fd5e-7e6e-4b2b-be76-3deb47b30c05",\n "voltype": "LEAF"\n}', 'stderr': '', 'rc': 0, 'cmd': ['vdsm-client', 'Volume', 'getInfo', 'storagepoolID=e6d35c1a-ad0c-11f0-a750-00163e67b4b6', 'storagedomainID=08d9d3f1-86fe-4159-95a8-bd686f44716d', 'imageID=0d4c388c-37a8-4161-9e5b-874af83c03c7', 'volumeID=1c41fd5e-7e6e-4b2b-be76-3deb47b30c05'], 'start': '2025-10-19 19:13:28.803335', 'end': '2025-10-19 19:13:29.074381', 'delta': '0:00:00.271046', 'msg': '', 'invocation': {'module_args': {'_raw_params': 'vdsm-client Volume getInfo storagepoolID=e6d35c1a-ad0c-11f0-a750-00163e67b4b6 storagedomainID=08d9d3f1-86fe-4159-95a8-bd686f44716d imageID=0d4c388c-37a8-4161-9e5b-874af83c03c7 volumeID=1c41fd5e-7e6e-4b2b-be76-3deb47b30c05', '_uses_shell': False, 'stdin_add_newline': True, 'strip_empty_ends': True, 'argv': None, 'chdir': None, 'executable': None, 'creates': None, 'removes': None, 'stdin': None}}, 'stdout_lines': ['{', ' "apparentsize": "134217728",', ' "capacity": "134217728",', ' "children": [],', ' "ctime": "1760893778",', ' "description": "{\\"DiskAlias\\":\\"OVF_STORE\\",\\"DiskDescription\\":\\"OVF_STORE\\"}",', ' "disktype": "OVFS",', ' "domain": "08d9d3f1-86fe-4159-95a8-bd686f44716d",', ' "format": "RAW",', ' "generation": 0,', ' "image": "0d4c388c-37a8-4161-9e5b-874af83c03c7",', ' "lease": {', ' "offset": 106954752,', ' "owners": [],', ' "path": "/dev/08d9d3f1-86fe-4159-95a8-bd686f44716d/leases",', ' "version": null', ' },', ' "legality": "LEGAL",', ' "mtime": "0",', ' "parent": "00000000-0000-0000-0000-000000000000",', ' "pool": "",', ' "sequence": 1,', ' "status": "OK",', ' "truesize": "134217728",', ' "type": "PREALLOCATED",', ' "uuid": "1c41fd5e-7e6e-4b2b-be76-3deb47b30c05",', ' "voltype": "LEAF"', '}'], 'stderr_lines': [], '_ansible_no_log': False, 'failed': True, 'attempts': 12, 'item': {'name': 'OVF_STORE', 'image_id': '1c41fd5e-7e6e-4b2b-be76-3deb47b30c05', 'id': '0d4c388c-37a8-4161-9e5b-874af83c03c7'}, 'ansible_loop_var': 'item', '_ansible_item_label': {'name': 'OVF_STORE', 'image_id': '1c41fd5e-7e6e-4b2b-be76-3deb47b30c05', 'id': '0d4c388c-37a8-4161-9e5b-874af83c03c7'}} 2025-10-19 19:15:36,481+0200 ERROR otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:113 {'changed': True, 'stdout': '{\n "apparentsize": "134217728",\n "capacity": "134217728",\n "children": [],\n "ctime": "1760893778",\n "description": "{\\"DiskAlias\\":\\"OVF_STORE\\",\\"DiskDescription\\":\\"OVF_STORE\\"}",\n "disktype": "OVFS",\n "domain": "08d9d3f1-86fe-4159-95a8-bd686f44716d",\n "format": "RAW",\n "generation": 0,\n "image": "4e00f0d5-d002-47aa-98ea-cd4b55dc4a2d",\n "lease": {\n "offset": 105906176,\n "owners": [],\n "path": "/dev/08d9d3f1-86fe-4159-95a8-bd686f44716d/leases",\n "version": null\n },\n "legality": "LEGAL",\n "mtime": "0",\n "parent": "00000000-0000-0000-0000-000000000000",\n "pool": "",\n "sequence": 1,\n "status": "OK",\n "truesize": "134217728",\n "type": "PREALLOCATED",\n "uuid": "933a3401-13cf-49c8-81a2-0656926bb33d",\n "voltype": "LEAF"\n}', 'stderr': '', 'rc': 0, 'cmd': ['vdsm-client', 'Volume', 'getInfo', 'storagepoolID=e6d35c1a-ad0c-11f0-a750-00163e67b4b6', 'storagedomainID=08d9d3f1-86fe-4159-95a8-bd686f44716d', 'imageID=4e00f0d5-d002-47aa-98ea-cd4b55dc4a2d', 'volumeID=933a3401-13cf-49c8-81a2-0656926bb33d'], 'start': '2025-10-19 19:15:35.773925', 'end': '2025-10-19 19:15:36.051910', 'delta': '0:00:00.277985', 'msg': '', 'invocation': {'module_args': {'_raw_params': 'vdsm-client Volume getInfo storagepoolID=e6d35c1a-ad0c-11f0-a750-00163e67b4b6 storagedomainID=08d9d3f1-86fe-4159-95a8-bd686f44716d imageID=4e00f0d5-d002-47aa-98ea-cd4b55dc4a2d volumeID=933a3401-13cf-49c8-81a2-0656926bb33d', '_uses_shell': False, 'stdin_add_newline': True, 'strip_empty_ends': True, 'argv': None, 'chdir': None, 'executable': None, 'creates': None, 'removes': None, 'stdin': None}}, 'stdout_lines': ['{', ' "apparentsize": "134217728",', ' "capacity": "134217728",', ' "children": [],', ' "ctime": "1760893778",', ' "description": "{\\"DiskAlias\\":\\"OVF_STORE\\",\\"DiskDescription\\":\\"OVF_STORE\\"}",', ' "disktype": "OVFS",', ' "domain": "08d9d3f1-86fe-4159-95a8-bd686f44716d",', ' "format": "RAW",', ' "generation": 0,', ' "image": "4e00f0d5-d002-47aa-98ea-cd4b55dc4a2d",', ' "lease": {', ' "offset": 105906176,', ' "owners": [],', ' "path": "/dev/08d9d3f1-86fe-4159-95a8-bd686f44716d/leases",', ' "version": null', ' },', ' "legality": "LEGAL",', ' "mtime": "0",', ' "parent": "00000000-0000-0000-0000-000000000000",', ' "pool": "",', ' "sequence": 1,', ' "status": "OK",', ' "truesize": "134217728",', ' "type": "PREALLOCATED",', ' "uuid": "933a3401-13cf-49c8-81a2-0656926bb33d",', ' "voltype": "LEAF"', '}'], 'stderr_lines': [], '_ansible_no_log': False, 'failed': True, 'attempts': 12, 'item': {'name': 'OVF_STORE', 'image_id': '933a3401-13cf-49c8-81a2-0656926bb33d', 'id': '4e00f0d5-d002-47aa-98ea-cd4b55dc4a2d'}, 'ansible_loop_var': 'item', '_ansible_item_label': {'name': 'OVF_STORE', 'image_id': '933a3401-13cf-49c8-81a2-0656926bb33d', 'id': '4e00f0d5-d002-47aa-98ea-cd4b55dc4a2d'}} 2025-10-19 19:15:59,830+0200 ERROR otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:113 fatal: [localhost]: FAILED! => {"changed": false, "msg": "The system may not be provisioned according to the playbook results: please check the logs for the issue, fix accordingly or re-deploy from scratch.\n"} 2025-10-19 19:16:00,155+0200 ERROR otopi.context context._executeMethod:151 Failed to execute stage 'Closing up': Failed executing ansible-playbook 2025-10-19 19:16:32,551+0200 ERROR otopi.context context._executeMethod:151 Failed to execute stage 'Clean up': [Errno 2] No such file or directory: '/var/lib/ovirt-hosted-engine-setup/answers/answers-20251019191632.conf' 2025-10-19 19:16:32,597+0200 ERROR otopi.plugins.gr_he_common.core.misc misc._terminate:164 Hosted Engine deployment failed: please check the logs for the issue, fix accordingly or re-deploy from scratch.

2 2