- Users - oVirt List Archives

Failed to flush the refcount block cache: No space left on device
by Devin A. Bougie 22 Mar '26

22 Mar '26

We have an oVirt 4.5.6 cluster with a self-hosted engine and 92 virtual machines, and run a monthly cron job to snapshot and then clone each VM for disaster recovery. This works fine for 91 of our VMs, but recently started failing on our VM with the largest disks (two 3TB drives) with "Failed to flush the refcount block cache: No space left on device.” My reading of the error must be wrong, but it seems to be saying that storage domain "86867486-e14e-4ff4-bf7c-1b0c94816032” is filling up? This is the “Data (Master)” iSCSI domain that the VM’s disks are on, and the oVirt GUI says it has plenty of space: Size: 66559 GiB Available: 46359 GiB Used: 20200 GiB Allocated: 22589 GiB The operation fails while cloning the snapshot into a new VM. The new VM is created and the disks are successful created, but the clone fails after several hours. Neither the SPM host nor the host the operation is running on (the host the hosted-engine is running on) see any filesystems filling up from the underlying host OS. The full excerpt of the error from engine.log is below. I’d greatly appreciate any help determining what exactly is filling up and how to fix it. Many thanks, Devin PS. Please disregard my previous posts - been struggling to figure out exactly what’s going on. ——— 2026-03-19 21:40:05,508-04 INFO [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-71) [] BaseAsyncTask::onTaskEndSuccess: Task '8eb13f96-8a66-4559-a0e8-c7ff109410f6' (Parent Command 'AddVmFromSnapshot', Parameters Type 'org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters') ended successfully. 2026-03-19 21:40:05,508-04 INFO [org.ovirt.engine.core.bll.CommandMultiAsyncTasks] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-71) [] Task with DB Task ID '4e0cafe5-624a-410e-a2c4-d072c47e8571' and VDSM Task ID '5a7d25ac-1ab9-4f69-85a3-9e8e081857d3' is in state Polling. End action for command c6340f4e-ddb0-4e1d-ba3a-ac82e9ee4164 will proceed when all the entity's tasks are completed. 2026-03-19 21:40:15,544-04 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksStatusesVDSCommand] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-92) [] Failed in 'HSMGetAllTasksStatusesVDS' method 2026-03-19 21:40:15,552-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-92) [] EVENT_ID: VDS_BROKER_COMMAND_FAILURE(10,802), VDSM lnxvirt06 command HSMGetAllTasksStatusesVDS failed: value=low level Image copy failed: ("Command ['/usr/bin/qemu-img', 'convert', '-p', '-t', 'none', '-T', 'none', '-f', 'qcow2', '-O', 'qcow2', '-o', 'compat=1.1', '/rhev/data-center/mnt/blockSD/86867486-e14e-4ff4-bf7c-1b0c94816032/images/211e91b0-2c72-45ad-90ca-badc63cb03f3/0a1b650f-8ab5-4eef-bee0-ea557c6eeb9f', '/rhev/data-center/mnt/blockSD/86867486-e14e-4ff4-bf7c-1b0c94816032/images/5bfb9a05-103c-4041-8f94-098f1be88c67/93bbfbab-7a62-49d4-bb27-dd939dd830d0'] failed with rc=1 out=b'' err=bytearray(b'qemu-img: error while writing at byte 3220932263936: No space left on device\\nqemu-img: Failed to flush the refcount block cache: No space left on device\\n')",) abortedcode=261 2026-03-19 21:40:15,552-04 INFO [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-92) [] SPMAsyncTask::PollTask: Polling task '5a7d25ac-1ab9-4f69-85a3-9e8e081857d3' (Parent Command 'AddVmFromSnapshot', Parameters Type 'org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters') returned status 'finished', result 'cleanSuccess'. 2026-03-19 21:40:15,554-04 ERROR [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-92) [] BaseAsyncTask::logEndTaskFailure: Task '5a7d25ac-1ab9-4f69-85a3-9e8e081857d3' (Parent Command 'AddVmFromSnapshot', Parameters Type 'org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters') ended with failure: 2026-03-19 21:40:15,557-04 INFO [org.ovirt.engine.core.bll.tasks.CommandAsyncTask] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-92) [] CommandAsyncTask::endActionIfNecessary: All tasks of command 'c6340f4e-ddb0-4e1d-ba3a-ac82e9ee4164' has ended -> executing 'endAction' 2026-03-19 21:40:15,557-04 INFO [org.ovirt.engine.core.bll.tasks.CommandAsyncTask] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-92) [] CommandAsyncTask::endAction: Ending action for '2' tasks (command ID: 'c6340f4e-ddb0-4e1d-ba3a-ac82e9ee4164'): calling endAction '. 2026-03-19 21:40:15,557-04 INFO [org.ovirt.engine.core.bll.tasks.CommandAsyncTask] (EE-ManagedThreadFactory-engine-Thread-838369) [] CommandAsyncTask::endCommandAction [within thread] context: Attempting to endAction 'AddVmFromSnapshot', 2026-03-19 21:40:15,597-04 ERROR [org.ovirt.engine.core.bll.AddVmFromSnapshotCommand] (EE-ManagedThreadFactory-engine-Thread-838369) [6492a8e8-1028-4504-9e56-9f22213f5f24] Ending command 'org.ovirt.engine.core.bll.AddVmFromSnapshotCommand' with failure. 2026-03-19 21:40:15,612-04 ERROR [org.ovirt.engine.core.bll.storage.disk.image.CopyImageGroupCommand] (EE-ManagedThreadFactory-engine-Thread-838369) [6492a8e8-1028-4504-9e56-9f22213f5f24] Ending command 'org.ovirt.engine.core.bll.storage.disk.image.CopyImageGroupCommand' with failure. 2026-03-19 21:40:15,626-04 INFO [org.ovirt.engine.core.bll.storage.disk.image.RemoveImageCommand] (EE-ManagedThreadFactory-engine-Thread-838369) [6492a8e8-1028-4504-9e56-9f22213f5f24] Running command: RemoveImageCommand internal: true. Entities affected : ID: 00000000-0000-0000-0000-000000000000 Type: Storage 2026-03-19 21:40:15,669-04 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.DeleteImageGroupVDSCommand] (EE-ManagedThreadFactory-engine-Thread-838369) [6492a8e8-1028-4504-9e56-9f22213f5f24] START, DeleteImageGroupVDSCommand( DeleteImageGroupVDSCommandParameters:{storagePoolId='00000001-0001-0001-0001-000000000311', ignoreFailoverLimit='false', storageDomainId='86867486-e14e-4ff4-bf7c-1b0c94816032', imageGroupId='5bfb9a05-103c-4041-8f94-098f1be88c67', postZeros='false', discard='false', forceDelete='false'}), log id: 32b75a5f 2026-03-19 21:40:15,797-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-838369) [6492a8e8-1028-4504-9e56-9f22213f5f24] EVENT_ID: IRS_BROKER_COMMAND_FAILURE(10,803), VDSM command DeleteImageGroupVDS failed: Image does not exist in domain: 'image=5bfb9a05-103c-4041-8f94-098f1be88c67, domain=86867486-e14e-4ff4-bf7c-1b0c94816032' 2026-03-19 21:40:15,798-04 ERROR [org.ovirt.engine.core.vdsbroker.irsbroker.DeleteImageGroupVDSCommand] (EE-ManagedThreadFactory-engine-Thread-838369) [6492a8e8-1028-4504-9e56-9f22213f5f24] Command 'DeleteImageGroupVDSCommand( DeleteImageGroupVDSCommandParameters:{storagePoolId='00000001-0001-0001-0001-000000000311', ignoreFailoverLimit='false', storageDomainId='86867486-e14e-4ff4-bf7c-1b0c94816032', imageGroupId='5bfb9a05-103c-4041-8f94-098f1be88c67', postZeros='false', discard='false', forceDelete='false'})' execution failed: IRSGenericException: IRSErrorException: Image does not exist in domain: 'image=5bfb9a05-103c-4041-8f94-098f1be88c67, domain=86867486-e14e-4ff4-bf7c-1b0c94816032' 2026-03-19 21:40:15,798-04 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.DeleteImageGroupVDSCommand] (EE-ManagedThreadFactory-engine-Thread-838369) [6492a8e8-1028-4504-9e56-9f22213f5f24] FINISH, DeleteImageGroupVDSCommand, return: , log id: 32b75a5f 2026-03-19 21:40:15,798-04 INFO [org.ovirt.engine.core.bll.storage.disk.image.RemoveImageCommand] (EE-ManagedThreadFactory-engine-Thread-838369) [6492a8e8-1028-4504-9e56-9f22213f5f24] Disk '5bfb9a05-103c-4041-8f94-098f1be88c67' doesn't exist on storage domain '86867486-e14e-4ff4-bf7c-1b0c94816032', rolling forward 2026-03-19 21:40:15,874-04 INFO [org.ovirt.engine.core.bll.tasks.AsyncTaskManager] (EE-ManagedThreadFactory-engine-Thread-838369) [6492a8e8-1028-4504-9e56-9f22213f5f24] Removed task 'cce0a49f-58b6-404d-8873-bd3b4d1465a4' from DataBase 2026-03-19 21:40:15,881-04 ERROR [org.ovirt.engine.core.bll.storage.disk.image.CopyImageGroupCommand] (EE-ManagedThreadFactory-engine-Thread-838369) [6492a8e8-1028-4504-9e56-9f22213f5f24] Ending command 'org.ovirt.engine.core.bll.storage.disk.image.CopyImageGroupCommand' with failure. 2026-03-19 21:40:15,887-04 INFO [org.ovirt.engine.core.bll.storage.disk.image.RemoveImageCommand] (EE-ManagedThreadFactory-engine-Thread-838369) [6492a8e8-1028-4504-9e56-9f22213f5f24] Running command: RemoveImageCommand internal: true. Entities affected : ID: 00000000-0000-0000-0000-000000000000 Type: Storage 2026-03-19 21:40:15,900-04 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.DeleteImageGroupVDSCommand] (EE-ManagedThreadFactory-engine-Thread-838369) [6492a8e8-1028-4504-9e56-9f22213f5f24] START, DeleteImageGroupVDSCommand( DeleteImageGroupVDSCommandParameters:{storagePoolId='00000001-0001-0001-0001-000000000311', ignoreFailoverLimit='false', storageDomainId='86867486-e14e-4ff4-bf7c-1b0c94816032', imageGroupId='b511da9e-e42c-4e7b-95d6-ab0262d19da1', postZeros='false', discard='false', forceDelete='false'}), log id: 48da38b0 2026-03-19 21:40:16,172-04 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.DeleteImageGroupVDSCommand] (EE-ManagedThreadFactory-engine-Thread-838369) [6492a8e8-1028-4504-9e56-9f22213f5f24] FINISH, DeleteImageGroupVDSCommand, return: , log id: 48da38b0 2026-03-19 21:40:16,173-04 INFO [org.ovirt.engine.core.bll.tasks.CommandAsyncTask] (EE-ManagedThreadFactory-engine-Thread-838369) [6492a8e8-1028-4504-9e56-9f22213f5f24] CommandAsyncTask::Adding CommandMultiAsyncTasks object for command 'a06dd36e-3a2d-4e19-94d5-90fa8aa861e4' 2026-03-19 21:40:16,173-04 INFO [org.ovirt.engine.core.bll.CommandMultiAsyncTasks] (EE-ManagedThreadFactory-engine-Thread-838369) [6492a8e8-1028-4504-9e56-9f22213f5f24] CommandMultiAsyncTasks::attachTask: Attaching task '20c9a088-6790-49d2-9b0d-9fdcf424e868' to command 'a06dd36e-3a2d-4e19-94d5-90fa8aa861e4'. 2026-03-19 21:40:16,180-04 INFO [org.ovirt.engine.core.bll.tasks.AsyncTaskManager] (EE-ManagedThreadFactory-engine-Thread-838369) [6492a8e8-1028-4504-9e56-9f22213f5f24] Adding task '20c9a088-6790-49d2-9b0d-9fdcf424e868' (Parent Command 'RemoveImage', Parameters Type 'org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters'), polling hasn't started yet.. 2026-03-19 21:40:16,184-04 INFO [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (EE-ManagedThreadFactory-engine-Thread-838369) [6492a8e8-1028-4504-9e56-9f22213f5f24] BaseAsyncTask::startPollingTask: Starting to poll task '20c9a088-6790-49d2-9b0d-9fdcf424e868'. 2026-03-19 21:40:16,185-04 INFO [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (EE-ManagedThreadFactory-engine-Thread-838369) [6492a8e8-1028-4504-9e56-9f22213f5f24] BaseAsyncTask::startPollingTask: Starting to poll task '20c9a088-6790-49d2-9b0d-9fdcf424e868'. 2026-03-19 21:40:16,216-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedThreadFactory-engine-Thread-838369) [] EVENT_ID: USER_ADD_VM_FINISHED_FAILURE(60), Failed to complete VM VS1_bk_20260319_133427 creation. 2026-03-19 21:40:16,216-04 INFO [org.ovirt.engine.core.bll.tasks.CommandAsyncTask] (EE-ManagedThreadFactory-engine-Thread-838369) [] CommandAsyncTask::HandleEndActionResult [within thread]: endAction for action type 'AddVmFromSnapshot' completed, handling the result. 2026-03-19 21:40:16,216-04 INFO [org.ovirt.engine.core.bll.tasks.CommandAsyncTask] (EE-ManagedThreadFactory-engine-Thread-838369) [] CommandAsyncTask::HandleEndActionResult [within thread]: endAction for action type 'AddVmFromSnapshot' succeeded, clearing tasks. 2026-03-19 21:40:16,216-04 INFO [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (EE-ManagedThreadFactory-engine-Thread-838369) [] SPMAsyncTask::ClearAsyncTask: Attempting to clear task '5a7d25ac-1ab9-4f69-85a3-9e8e081857d3' 2026-03-19 21:40:16,216-04 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.SPMClearTaskVDSCommand] (EE-ManagedThreadFactory-engine-Thread-838369) [] START, SPMClearTaskVDSCommand( SPMTaskGuidBaseVDSCommandParameters:{storagePoolId='00000001-0001-0001-0001-000000000311', ignoreFailoverLimit='false', taskId='5a7d25ac-1ab9-4f69-85a3-9e8e081857d3'}), log id: 11fe9bb5 2026-03-19 21:40:16,217-04 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMClearTaskVDSCommand] (EE-ManagedThreadFactory-engine-Thread-838369) [] START, HSMClearTaskVDSCommand(HostName = lnxvirt06, HSMTaskGuidBaseVDSCommandParameters:{hostId='98e9372d-e2cb-4cfa-bae9-e90a5990193f', taskId='5a7d25ac-1ab9-4f69-85a3-9e8e081857d3'}), log id: 3e60a41d 2026-03-19 21:40:16,233-04 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMClearTaskVDSCommand] (EE-ManagedThreadFactory-engine-Thread-838369) [] FINISH, HSMClearTaskVDSCommand, return: , log id: 3e60a41d 2026-03-19 21:40:16,233-04 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.SPMClearTaskVDSCommand] (EE-ManagedThreadFactory-engine-Thread-838369) [] FINISH, SPMClearTaskVDSCommand, return: , log id: 11fe9bb5 2026-03-19 21:40:16,235-04 INFO [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (EE-ManagedThreadFactory-engine-Thread-838369) [] BaseAsyncTask::removeTaskFromDB: Removed task '5a7d25ac-1ab9-4f69-85a3-9e8e081857d3' from DataBase 2026-03-19 21:40:16,235-04 INFO [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (EE-ManagedThreadFactory-engine-Thread-838369) [] SPMAsyncTask::ClearAsyncTask: Attempting to clear task '8eb13f96-8a66-4559-a0e8-c7ff109410f6' 2026-03-19 21:40:16,235-04 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.SPMClearTaskVDSCommand] (EE-ManagedThreadFactory-engine-Thread-838369) [] START, SPMClearTaskVDSCommand( SPMTaskGuidBaseVDSCommandParameters:{storagePoolId='00000001-0001-0001-0001-000000000311', ignoreFailoverLimit='false', taskId='8eb13f96-8a66-4559-a0e8-c7ff109410f6'}), log id: 53d1be35 2026-03-19 21:40:16,235-04 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMClearTaskVDSCommand] (EE-ManagedThreadFactory-engine-Thread-838369) [] START, HSMClearTaskVDSCommand(HostName = lnxvirt06, HSMTaskGuidBaseVDSCommandParameters:{hostId='98e9372d-e2cb-4cfa-bae9-e90a5990193f', taskId='8eb13f96-8a66-4559-a0e8-c7ff109410f6'}), log id: 5950a159 2026-03-19 21:40:16,242-04 INFO [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMClearTaskVDSCommand] (EE-ManagedThreadFactory-engine-Thread-838369) [] FINISH, HSMClearTaskVDSCommand, return: , log id: 5950a159 2026-03-19 21:40:16,242-04 INFO [org.ovirt.engine.core.vdsbroker.irsbroker.SPMClearTaskVDSCommand] (EE-ManagedThreadFactory-engine-Thread-838369) [] FINISH, SPMClearTaskVDSCommand, return: , log id: 53d1be35 2026-03-19 21:40:16,244-04 INFO [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (EE-ManagedThreadFactory-engine-Thread-838369) [] BaseAsyncTask::removeTaskFromDB: Removed task '8eb13f96-8a66-4559-a0e8-c7ff109410f6' from DataBase 2026-03-19 21:40:16,244-04 INFO [org.ovirt.engine.core.bll.tasks.CommandAsyncTask] (EE-ManagedThreadFactory-engine-Thread-838369) [] CommandAsyncTask::HandleEndActionResult [within thread]: Removing CommandMultiAsyncTasks object for entity 'c6340f4e-ddb0-4e1d-ba3a-ac82e9ee4164' 2026-03-19 21:40:16,948-04 INFO [org.ovirt.engine.core.sso.servlets.OAuthRevokeServlet] (default task-112) [] User admin@internal-authz with profile [internal] successfully logged out 2026-03-19 21:40:16,957-04 INFO [org.ovirt.engine.core.bll.aaa.TerminateSessionsForTokenCommand] (default task-113) [d2601da] Running command: TerminateSessionsForTokenCommand internal: true. 2026-03-19 21:40:25,557-04 INFO [org.ovirt.engine.core.bll.tasks.AsyncTaskManager] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-80) [] Polling and updating Async Tasks: 5 tasks, 1 tasks to poll now 2026-03-19 21:40:25,579-04 INFO [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-80) [] SPMAsyncTask::PollTask: Polling task '20c9a088-6790-49d2-9b0d-9fdcf424e868' (Parent Command 'RemoveImage', Parameters Type 'org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters') returned status 'finished', result 'success'. 2026-03-19 21:40:25,579-04 INFO [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-80) [] BaseAsyncTask::onTaskEndSuccess: Task '20c9a088-6790-49d2-9b0d-9fdcf424e868' (Parent Command 'RemoveImage', Parameters Type 'org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters') ended successfully. 2026-03-19 21:40:25,581-04 INFO [org.ovirt.engine.core.bll.tasks.CommandAsyncTask] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-80) [] CommandAsyncTask::endActionIfNecessary: All tasks of command 'a06dd36e-3a2d-4e19-94d5-90fa8aa861e4' has ended -> executing 'endAction' 2026-03-19 21:40:25,581-04 INFO [org.ovirt.engine.core.bll.tasks.CommandAsyncTask] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-80) [] CommandAsyncTask::endAction: Ending action for '1' tasks (command ID: 'a06dd36e-3a2d-4e19-94d5-90fa8aa861e4'): calling endAction '. 2026-03-19 21:40:25,581-04 INFO [org.ovirt.engine.core.bll.tasks.CommandAsyncTask] (EE-ManagedThreadFactory-engine-Thread-838373) [] CommandAsyncTask::endCommandAction [within thread] context: Attempting to endAction 'CopyImageGroup', 2026-03-19 21:40:25,581-04 ERROR [org.ovirt.engine.core.bll.tasks.CommandAsyncTask] (EE-ManagedThreadFactory-engine-Thread-838373) [] [within thread]: endAction for action type CopyImageGroup threw an exception.: java.lang.NullPointerException 2026-03-19 21:40:25,581-04 INFO [org.ovirt.engine.core.bll.tasks.CommandAsyncTask] (EE-ManagedThreadFactory-engine-Thread-838373) [] CommandAsyncTask::HandleEndActionResult: endAction for action type 'RemoveImage' threw an unrecoverable RuntimeException the task will be cleared. 2026-03-19 21:40:25,584-04 INFO [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (EE-ManagedThreadFactory-engine-Thread-838373) [] BaseAsyncTask::removeTaskFromDB: Removed task '20c9a088-6790-49d2-9b0d-9fdcf424e868' from DataBase 2026-03-19 21:40:25,584-04 INFO [org.ovirt.engine.core.bll.tasks.CommandAsyncTask] (EE-ManagedThreadFactory-engine-Thread-838373) [] CommandAsyncTask::HandleEndActionRuntimeException: Removing CommandMultiAsyncTasks object for entity 'a06dd36e-3a2d-4e19-94d5-90fa8aa861e4’ ———

1 0

Reclaim space from iSCSI storage domain
by Devin A. Bougie 20 Mar '26

20 Mar '26

We have an oVirt 4.5.6 cluster with a self-hosted engine with an iSCSI Data (Master) domain. The oVirt UI shows that it has plenty of space: Size: 66559 GiB Available: 46359 GiB Used: 20200 GiB Allocated: 22589 GiB When trying to create a new disk, however, we receive the errors below complaining that the Volume Group has insufficient free space. How can we safely reclaim this space, ideally without shutting down ever VM that’s using this storage domain? Although “multipath -ll” shows the underlying devices on the host machines, the normal “pvs / vgs / lvs” commands don’t see them. Many thanks, Devin ——— 2026-03-20 14:39:13,038-04 ERROR [org.ovirt.engine.core.vdsbroker.vdsbroker.HSMGetAllTasksStatusesVDSCommand] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-31) [] Failed in 'HSMGetAllTasksStatusesVDS' method 2026-03-20 14:39:13,080-04 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-31) [] EVENT_ID: VDS_BROKER_COMMAND_FAILURE(10,802), VDSM lnxvirt06 command HSMGetAllTasksStatusesVDS failed: value=Cannot create Logical Volume: 'cmd=[\'/sbin/lvm\', \'lvcreate\', \'--devices\', \'/dev/mapper/mpathd,/dev/mapper/mpathj,/dev/mapper/mpathm\', \'--config\', \'devices { preferred_names=["^/dev/mapper/"] ignore_suspended_devices=1 write_cache_state=0 disable_after_error_count=3 hints="none" obtain_device_list_from_udev=0 } global { prioritise_write_locks=1 wait_for_locks=1 use_lvmpolld=1 } backup { retain_min=50 retain_days=0 }\', \'--autobackup\', \'n\', \'--contiguous\', \'n\', \'--size\', \'3072000m\', \'--wipesignatures\', \'n\', \'--addtag\', \'OVIRT_VOL_INITIALIZING\', \'--name\', \'3b8c4d37-0807-4a16-8dcf-f6aee207b4e6\', \'4f1e2b92-fe8d-47ef-b0ba-a9c7501bf254\'] rc=5 out=[] err=[\' Volume group "4f1e2b92-fe8d-47ef-b0ba-a9c7501bf254" has insufficient free space (7726 extents): 24000 required.\']' abortedcode=550 2026-03-20 14:39:13,080-04 INFO [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-31) [] SPMAsyncTask::PollTask: Polling task '4f9a9858-290b-4ed8-9a42-0bc8d4d7aca6' (Parent Command 'AddImageFromScratch', Parameters Type 'org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters') returned status 'finished', result 'cleanSuccess'. 2026-03-20 14:39:13,083-04 ERROR [org.ovirt.engine.core.bll.tasks.SPMAsyncTask] (EE-ManagedScheduledExecutorService-engineScheduledThreadPool-Thread-31) [] BaseAsyncTask::logEndTaskFailure: Task '4f9a9858-290b-4ed8-9a42-0bc8d4d7aca6' (Parent Command 'AddImageFromScratch', Parameters Type 'org.ovirt.engine.core.common.asynctasks.AsyncTaskParameters') ended with failure: -- Result: 'cleanSuccess' -- Message: 'VDSGenericException: VDSErrorException: Failed to HSMGetAllTasksStatusesVDS, error = value=Cannot create Logical Volume: 'cmd=[\'/sbin/lvm\', \'lvcreate\', \'--devices\', \'/dev/mapper/mpathd,/dev/mapper/mpathj,/dev/mapper/mpathm\', \'--config\', \'devices { preferred_names=["^/dev/mapper/"] ignore_suspended_devices=1 write_cache_state=0 disable_after_error_count=3 hints="none" obtain_device_list_from_udev=0 } global { prioritise_write_locks=1 wait_for_locks=1 use_lvmpolld=1 } backup { retain_min=50 retain_days=0 }\', \'--autobackup\', \'n\', \'--contiguous\', \'n\', \'--size\', \'3072000m\', \'--wipesignatures\', \'n\', \'--addtag\', \'OVIRT_VOL_INITIALIZING\', \'--name\', \'3b8c4d37-0807-4a16-8dcf-f6aee207b4e6\', \'4f1e2b92-fe8d-47ef-b0ba-a9c7501bf254\'] rc=5 out=[] err=[\' Volume group "4f1e2b92-fe8d-47ef-b0ba-a9c7501bf254" has insufficient free space (7726 extents): 24000 required.\']' abortedcode=550, code = 550', -- Exception: 'VDSGenericException: VDSErrorException: Failed to HSMGetAllTasksStatusesVDS, error = value=Cannot create Logical Volume: 'cmd=[\'/sbin/lvm\', \'lvcreate\', \'--devices\', \'/dev/mapper/mpathd,/dev/mapper/mpathj,/dev/mapper/mpathm\', \'--config\', \'devices { preferred_names=["^/dev/mapper/"] ignore_suspended_devices=1 write_cache_state=0 disable_after_error_count=3 hints="none" obtain_device_list_from_udev=0 } global { prioritise_write_locks=1 wait_for_locks=1 use_lvmpolld=1 } backup { retain_min=50 retain_days=0 }\', \'--autobackup\', \'n\', \'--contiguous\', \'n\', \'--size\', \'3072000m\', \'--wipesignatures\', \'n\', \'--addtag\', \'OVIRT_VOL_INITIALIZING\', \'--name\', \'3b8c4d37-0807-4a16-8dcf-f6aee207b4e6\', \'4f1e2b92-fe8d-47ef-b0ba-a9c7501bf254\'] rc=5 out=[] err=[\' Volume group "4f1e2b92-fe8d-47ef-b0ba-a9c7501bf254" has insufficient free space (7726 extents): 24000 required.\']' abortedcode=550, code = 550’ ———

1 0

Re: Reattach gluster brick after rebuilt hypervisor
by Jeremy Tourville 20 Mar '26

20 Mar '26

I got a little further but just wanted to confirm a scenario. I realized part of my issue was due to having the volume mounted. I unmounted it and the message I get changed. cd / umount /gluster_bricks/vmstore now comment out /etc/fstab, systemctl daemon-reload and mount -a to confirm it is no longer mounted. [root@vmh /]# gluster volume create vmstore vmh.tourville.org:/gluster_bricks/vmstore volume create: vmstore: failed: The brick vmh.tourville.org:/gluster_bricks/vmstore is being created in the root partition. It is recommended that you don't use the system's root partition for storage backend. Or use 'force' at the end of the command if you want to override this behavior. ## DISK LAYOUT [root@vmh /]# vgs VG #PV #LV #SN Attr VSize VFree gluster_vg_sda 1 2 0 wz--n- <5.46t 0 rl_vmh 1 10 0 wz--n- <219.18g <43.84g [root@vmh /]# lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert gluster_lv_vmstore gluster_vg_sda Vwi-a-t--- 4.39t gluster_thinpool_gluster_vg_sda 48.48 gluster_thinpool_gluster_vg_sda gluster_vg_sda twi-aot--- <5.43t 39.26 0.51 home rl_vmh Vwi-aotz-- 70.00g pool00 0.09 pool00 rl_vmh twi-aotz-- <171.01g 4.36 11.17 root rl_vmh Vwi-aotz-- 20.00g pool00 22.29 swap rl_vmh -wi-ao---- 4.00g tmp rl_vmh Vwi-aotz-- 6.00g pool00 1.20 var rl_vmh Vwi-aotz-- 30.00g pool00 7.56 var_crash rl_vmh Vwi-aotz-- 15.00g pool00 0.42 var_log rl_vmh Vwi-aotz-- 16.00g pool00 0.84 var_log_audit rl_vmh Vwi-aotz-- 4.00g pool00 1.70 var_tmp rl_vmh Vwi-aotz-- 10.00g pool00 3.35 [root@vmh /]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 5.5T 0 disk └─3600605b00a2faca2233aa64a0966bb09 253:14 0 5.5T 0 mpath ├─gluster_vg_sda-gluster_thinpool_gluster_vg_sda_tmeta 253:16 0 15.8G 0 lvm │ └─gluster_vg_sda-gluster_thinpool_gluster_vg_sda-tpool 253:18 0 5.4T 0 lvm │ ├─gluster_vg_sda-gluster_thinpool_gluster_vg_sda 253:19 0 5.4T 1 lvm │ └─gluster_vg_sda-gluster_lv_vmstore 253:20 0 4.4T 0 lvm └─gluster_vg_sda-gluster_thinpool_gluster_vg_sda_tdata 253:17 0 5.4T 0 lvm └─gluster_vg_sda-gluster_thinpool_gluster_vg_sda-tpool 253:18 0 5.4T 0 lvm ├─gluster_vg_sda-gluster_thinpool_gluster_vg_sda 253:19 0 5.4T 1 lvm └─gluster_vg_sda-gluster_lv_vmstore 253:20 0 4.4T 0 lvm sdb 8:16 0 223.6G 0 disk └─sdb1 8:17 0 219.3G 0 part └─md127 9:127 0 219.2G 0 raid1 ├─rl_vmh-pool00_tmeta 253:0 0 172M 0 lvm │ └─rl_vmh-pool00-tpool 253:2 0 171G 0 lvm │ ├─rl_vmh-root 253:3 0 20G 0 lvm / │ ├─rl_vmh-pool00 253:5 0 171G 1 lvm │ ├─rl_vmh-home 253:6 0 70G 0 lvm /home │ ├─rl_vmh-var_crash 253:7 0 15G 0 lvm /var/crash │ ├─rl_vmh-tmp 253:8 0 6G 0 lvm /tmp │ ├─rl_vmh-var_tmp 253:9 0 10G 0 lvm /var/tmp │ ├─rl_vmh-var_log_audit 253:10 0 4G 0 lvm /var/log/audit │ ├─rl_vmh-var_log 253:11 0 16G 0 lvm /var/log │ └─rl_vmh-var 253:12 0 30G 0 lvm /var ├─rl_vmh-pool00_tdata 253:1 0 171G 0 lvm │ └─rl_vmh-pool00-tpool 253:2 0 171G 0 lvm │ ├─rl_vmh-root 253:3 0 20G 0 lvm / │ ├─rl_vmh-pool00 253:5 0 171G 1 lvm │ ├─rl_vmh-home 253:6 0 70G 0 lvm /home │ ├─rl_vmh-var_crash 253:7 0 15G 0 lvm /var/crash │ ├─rl_vmh-tmp 253:8 0 6G 0 lvm /tmp │ ├─rl_vmh-var_tmp 253:9 0 10G 0 lvm /var/tmp │ ├─rl_vmh-var_log_audit 253:10 0 4G 0 lvm /var/log/audit │ ├─rl_vmh-var_log 253:11 0 16G 0 lvm /var/log │ └─rl_vmh-var 253:12 0 30G 0 lvm /var └─rl_vmh-swap 253:4 0 4G 0 lvm [SWAP] sdc 8:32 0 223.6G 0 disk ├─sdc1 8:33 0 600M 0 part /boot/efi ├─sdc2 8:34 0 1M 0 part ├─sdc3 8:35 0 1G 0 part /boot └─sdc4 8:36 0 219.3G 0 part └─md127 9:127 0 219.2G 0 raid1 ├─rl_vmh-pool00_tmeta 253:0 0 172M 0 lvm │ └─rl_vmh-pool00-tpool 253:2 0 171G 0 lvm │ ├─rl_vmh-root 253:3 0 20G 0 lvm / │ ├─rl_vmh-pool00 253:5 0 171G 1 lvm │ ├─rl_vmh-home 253:6 0 70G 0 lvm /home │ ├─rl_vmh-var_crash 253:7 0 15G 0 lvm /var/crash │ ├─rl_vmh-tmp 253:8 0 6G 0 lvm /tmp │ ├─rl_vmh-var_tmp 253:9 0 10G 0 lvm /var/tmp │ ├─rl_vmh-var_log_audit 253:10 0 4G 0 lvm /var/log/audit │ ├─rl_vmh-var_log 253:11 0 16G 0 lvm /var/log │ └─rl_vmh-var 253:12 0 30G 0 lvm /var ├─rl_vmh-pool00_tdata 253:1 0 171G 0 lvm │ └─rl_vmh-pool00-tpool 253:2 0 171G 0 lvm │ ├─rl_vmh-root 253:3 0 20G 0 lvm / │ ├─rl_vmh-pool00 253:5 0 171G 1 lvm │ ├─rl_vmh-home 253:6 0 70G 0 lvm /home │ ├─rl_vmh-var_crash 253:7 0 15G 0 lvm /var/crash │ ├─rl_vmh-tmp 253:8 0 6G 0 lvm /tmp │ ├─rl_vmh-var_tmp 253:9 0 10G 0 lvm /var/tmp │ ├─rl_vmh-var_log_audit 253:10 0 4G 0 lvm /var/log/audit │ ├─rl_vmh-var_log 253:11 0 16G 0 lvm /var/log │ └─rl_vmh-var 253:12 0 30G 0 lvm /var └─rl_vmh-swap 253:4 0 4G 0 lvm [SWAP] sdd 8:48 0 596.2G 0 disk └─Hitachi_HTS547564A9E384_J21B0053G8E15R 253:13 0 596.2G 0 mpath └─Hitachi_HTS547564A9E384_J21B0053G8E15R1 253:15 0 596.2G 0 part So I think I can do a force because they are on different VGs. Can anyone confirm? Is there an unseen scenario (IE- bad practices) where forcing could cause issues?

1 0

Reattach gluster brick after rebuilt hypervisor
by Jeremy Tourville 20 Mar '26

20 Mar '26

I have a gluster volume that was created using an older version 4.x of oVirt. This was so long ago I am not sure I remember how I did it except that I used the wizard and the built in ansible job. I recently rebuilt my system that is hyperconverged. The storage raid array (hardware backed) is in my hypervisor. The engine is a stand alone external device. I am now at ver 4.5.7 of Ovirt. I want to add my gluster brick back into the setup. I have reviewed the wiki notes but they presume a new build, not my scenario. From what I read and researched, I think I need to create a distributed brick. How do you do that with just a single system when there is no replication to other hosts? Can anyone share a general procedure? ##DIAGNOSTICS [root@vmh /]# mount ... /dev/mapper/gluster_vg_sda-gluster_lv_vmstore on /gluster_bricks/vmstore type xfs (rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=256k,sunit=512,swidth=2048,noquota) [root@vmh /]# tail -n 1 /etc/fstab /dev/mapper/gluster_vg_sda-gluster_lv_vmstore /gluster_bricks/vmstore xfs defaults 0 0 [root@vmh /]# gluster volume create vmstore vmh.tourville.org:/gluster_bricks/vmstore volume create: vmstore: failed: The brick vmh.tourville.org:/gluster_bricks/vmstore is a mount point. Please create a sub-directory under the mount point and use that as the brick directory. Or use 'force' at the end of the command if you want to override this behavior. [root@vmh /]# gluster volume create vmstore vmh.tourville.org:/gluster_bricks/vmstore/vmstore volume create: vmstore: failed: /gluster_bricks/vmstore/vmstore is already part of a volume [root@vmh /]# tree /gluster_bricks/ /gluster_bricks/ └── vmstore └── vmstore └── 42c329c3-8eca-4748-af7a-f48aca494d72 ├── dom_md │ ├── ids │ ├── inbox │ ├── leases │ ├── metadata │ ├── outbox │ └── xleases ├── images │ ├── 019f828b-8f5d-47cf-bccd-7044402e7dd8 ... Do I need to force creation at this point? I just want to proceed cautiously at this point as I am not super confident with gluster. IE- [root@vmh /]# gluster volume create vmstore vmh.tourville.org:/gluster_bricks/vmstore force

1 0

hci setup with replica3 but one brick is not used
by Jiri Slezka 08 Mar '26

08 Mar '26

Hi, I am using distributed-replicated volume for vm's storage. There are 3 bricks (mounts on separate disks) in each of 3 hosts, so topology is 3x3 Volume Name: vms Type: Distributed-Replicate Volume ID: 52032ec6-99d4-4210-8fb8-ffbd7a1e0bf7 Status: Started Snapshot Count: 0 Number of Bricks: 3 x 3 = 9 Transport-type: tcp Bricks: Brick1: 10.0.4.11:/gluster_bricks/vms/vms Brick2: 10.0.4.13:/gluster_bricks/vms/vms Brick3: 10.0.4.12:/gluster_bricks/vms/vms Brick4: 10.0.4.11:/gluster_bricks/vms2/vms2 Brick5: 10.0.4.13:/gluster_bricks/vms2/vms2 Brick6: 10.0.4.12:/gluster_bricks/vms2/vms2 Brick7: 10.0.4.11:/gluster_bricks/vms3/vms3 Brick8: 10.0.4.12:/gluster_bricks/vms3/vms3 Brick9: 10.0.4.13:/gluster_bricks/vms3/vms3 I can see that bricks vms and vms2 are used but vms3 is almost (256MB vs hundreds of GBs) empty. In the fact I added vms3 bricks later and did not mention it because free volume space was reported (as I believed) correctly. Today I added one vm with 400GB disk and creating of disk failed because "OSError: [Errno 28] No space left on device". Now vms and vms2 bricks are full but vms volume has (should have) 914GiB of free space. I cannot see nothing interesting in glusterfs logs, glusterfs volume info and status looks good. There are errors in engine and vdsm logs but as can I see, it is just because of lack of space (vdsm side) and because image creation failed (engine side) Also as side effect, vms volume is full and disk from that new vm is locked (I would like to delete it). Any ideas what can be wrong or where to look and how to debug? Thanks in advance, Jiri

2 3

oVirt offline install
by Ethan Provensen 26 Feb '26

26 Feb '26

For the last 3-4 months, I have been trying to install oVirt on 3 bare metal servers with 1 SAN on an air-gapped network (no internet connection). I have failed with every attempt. I first determined what repositories I needed to upload to my air-gapped network to my Apache server, so the 3 bare metal servers could get the needed RPMs to install oVirt. I uploaded the following repositories from the internet: copr:copr.fedorainfracloud.org:ovirt:ovirt-master-snapshot ovirt-appliance-master-snapshot ovirt-master-centos-stream-ceph-pacific-testing ovirt-master-centos-stream-gluster10-testing ovirt-master-centos-stream-nfv-openvswitch2-testing ovirt-master-centos-stream-openstack-yoga-testing ovirt-master-centos-stream-opstools-collectd5-testing ovirt-master-centos-stream-ovirt45-testing ovirt-node-master-snapshot I first tried to install a oVirt self-hosted engine architecture on 1 server running Alma 9, but I ran into multiple dead ends with errors that I did not understand. My second attempt was to refresh the 1 Alma 9 server and install the oVirt CentOS9 node ISO instead on the 1 server. Again, I ran into multiple errors and did not understand the error messages. Recently, the oVirt Blog recommended we stopped using the oVirt CentOS9 node ISO for oVirt v4.5.7, so I went back on tried to install oVirt on Alma 9, and again I ran into multiple errors. I do not know what I am doing wrong. I have followed all the directions and Googled all the error messages I received, and still don't understand any of it. Now I am wondering if it's even possible to install oVirt on an server that doesn't have a DHCP connection to the internet. The last time I tried to create the "HostedEngineLocal" virtual machine on the server, I noticed the virtual machine creation relied on an internet connection and that is why the Hosted Engine setup failed everytime. Am I wrong? What am I doing wrong? Can someone help?

3 8

Deploy process frezzes with "Wait for the host to be up"
by Leandro Pereira 16 Feb '26

16 Feb '26

Hello everyone I'm installing ovirt 4.5 on a homelab VMWare Workstation (which I did several times weeks ago). Not so much that I'm going through technical problems. The deploy engine works in a stage called '[ INFO ] TASK [ovirt.ovirt.hosted_engine_setup : Wait for the host to be up]'. I couldn't find any error messages in both the Host logs and the Engine. Try different ways to automatically create the ovirtmgmt network, as you previously created it. The fact is that at this stage the engine is still not connected to the ovirtmgmt network, and from this point the depoloy does not pass through the host cannot communicate with the Engine with the FQDN informed.

4 4

Unable to deploy hosted engine. It keeps stuck wait for the host to be up.
by dushyantk.sun＠gmail.com 15 Feb '26

15 Feb '26

I am trying to deploy hosted engine 4.5 on OL8.10. However it keeps getting stuck at step "wait for the host to be up." without any error. During this i found that vdsm service and related services went down. I am able to ssh into temp local hosted engine. But installation just stuck there. Nothing in ovirt-hosted-engine-setup logs.

1 0

Expanding blockSD volume
by Devin A. Bougie 13 Feb '26

13 Feb '26

What is the proper procedure for expanding the “blockSD” volume in our ovirt 4.5.6 cluster? We’ve started getting "No space left on device” errors when trying to clone a snapshot into a VM for backup purposes. Here’s the error: ——— VDSM lnxvirt06 command HSMGetAllTasksStatusesVDS failed: value=low level Image copy failed: ("Command ['/usr/bin/qemu-img', 'convert', '-p', '-t', 'none', '-T', 'none', '-f', 'qcow2', '-O', 'qcow2', '-o', 'compat=1.1', '/rhev/data-center/mnt/blockSD/86867486-e14e-4ff4-bf7c-1b0c94816032/images/211e91b0-2c72-45ad-90ca-badc63cb03f3/0a1b650f-8ab5-4eef-bee0-ea557c6eeb9f', '/rhev/data-center/mnt/blockSD/86867486-e14e-4ff4-bf7c-1b0c94816032/images/a2d4cef1-0342-41c0-85c2-e1b2ba6768b1/017e6d7e-4016-4108-8edc-188d8096a719'] failed with rc=1 out=b'' err=bytearray(b'qemu-img: error while writing at byte 3220937441280: No space left on device\\nqemu-img: Failed to flush the refcount block cache: No space left on device\\n')",) abortedcode=261 ——— And here’s what the host OS shows: ——— [root@lnxvirt06 ~]# df -h |grep rhev ovirtfs:/mnt/ovirtbackup 75T 36T 40T 47% /rhev/data-center/mnt/ovirtfs:_mnt_ovirtbackup /dev/mapper/86867486--e14e--4ff4--bf7c--1b0c94816032-master 975M 84K 924M 1% /rhev/data-center/mnt/blockSD/86867486-e14e-4ff4-bf7c-1b0c94816032/master ——— Please let me know if there’s any more information I can provide. Many thanks, Devin

1 0

Hosted Engine Deployment timeout waiting for VM
by Jonas Liechti 09 Feb '26

09 Feb '26

Hello users, I am currently trying to deploy the self-hosted engine via the web interface but it seems stuck at the task "Wait for the local VM" (https://github.com/oVirt/ovirt-ansible-collection/blob/master/roles/hosted_…) I am unsure what to look at for getting more info as I haven't worked a lot with Ansible before. Do you have any idea how to debug? The temporary IP is added to /etc/hosts and I can also login to the VM via SSH: [root@server-005 ~]# cat /etc/hosts 192.168.1.97 ovirt-engine-test.admin.int.rabe.ch # temporary entry added by hosted-engine-setup for the bootstrap VM 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 10.128.16.5 server-005.admin.int.rabe.ch 10.128.16.6 server-006.admin.int.rabe.ch 10.128.16.7 server-007.admin.int.rabe.ch #10.128.32.2 ovirt-engine-test.admin.int.rabe.ch 10.132.16.5 server-005.storage.int.rabe.ch 10.132.16.6 server-006.storage.int.rabe.ch 10.132.16.7 server-007.storage.int.rabe.ch [root@server-005 ~]# ssh ovirt-engine-test.admin.int.rabe.ch root(a)ovirt-engine-test.admin.int.rabe.ch's password: Web console: https://ovirt-engine-test.admin.int.rabe.ch:9090/ or https://192.168.1.97:9090/ Last login: Mon Apr 18 11:33:53 2022 from 192.168.1.1 [root@ovirt-engine-test ~]# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 00:16:3e:58:7a:a3 brd ff:ff:ff:ff:ff:ff inet 192.168.1.97/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0 valid_lft 2313sec preferred_lft 2313sec inet6 fe80::216:3eff:fe58:7aa3/64 scope link valid_lft forever preferred_lft forever Thank you for any tips for debugging. Jonas

5 7

Odd behavior of VMs in Cluster
by dan.midthun＠gmail.com 08 Feb '26

08 Feb '26

I recently have had some odd / inconsistent behaviors with VMs that I am completely baffled by: packets being dropped for no apparent reason. This possibly started around 1/1/2026. I started having issues with maintaining connectivity to [vm2], and then more VMs on the cluster (specifically the engine!, then others) No sense. No config changes. No hardware changes. _NO_ changes. 2 vms, same host, same network, same storage, same configuration. ping google, vm1: 0% packet loss vm2: n% packet loss migrate host for vm2, no change. still packet loss. migrate host for vm1, no change, NO packet loss. mind you, these are clones. literally. the only difference is in configured IP address. I've been doing IT for the last 30 years, and I have NEVER seen anything like this. So, decided maybe update the hosts. (ikd ... why not)..... long story short, I am on Node 4.5.5 (was previously, too) now engine 4.5.7; still the same problem. What information is needed for someone to help me troubleshoot this issue

1 0

Upgrade to latest version
by Andrea Chierici 06 Feb '26

06 Feb '26

Hi, I am trying to update my old 4.5.5 system to the latest one, right now with no luck: I am writing to share some experience and hopefully to be pointed to the correct process. My system runs entirely on centos8, version is 4.5.5-1.el8, engine is on a vm hosted on vmware, no self hosted engine. The idea is to install a new engine vm, with almalinux10, import the backup taken from the old engine, and restore the system. After that I would upgrade all the hosts, one at a time. I tried today the first time, unsuccesfully. Here are all the steps: 1. take the almalinux10 vm, install the ovirt software with these commands: dnf copr enable -y ovirt/ovirt-master-snapshot rhel-10-x86_64 dnf install -y ovirt-release-master epel-release dnf install -y ovirt-engine Operation ended succesfully 2. import the backup taken from current 4.5.5 engine: engine-backup --mode=restore --scope=all --file=/backup.tar.gz --log=/tmp/restore.log --restore-permissions Operation ended successfully 3. Run engine-setup, here is the output (removed fqdn for privacy): --== CONFIGURATION PREVIEW ==-- Host FQDN : xxxxxxx.yyy.it Firewall manager : firewalld Update Firewall : True Set up Cinderlib integration : False Engine database host : localhost Engine database port : 5432 Engine database secured connection : False Engine database host name validation : False Engine database name : engine Engine database user name : engine Engine installation : True PKI organization : yyy.it Set up ovirt-provider-ovn : True DWH installation : True DWH database host : localhost DWH database port : 5432 DWH database secured connection : False DWH database host name validation : False DWH database name : ovirt_engine_history DWH database user name : ovirt_engine_history Backup DWH database : False Grafana integration : True Grafana database user name : ovirt_engine_history_grafana Configure VMConsole Proxy : True Configure WebSocket Proxy : True Please confirm installation settings (OK, Cancel) [OK]: [ INFO ] Cleaning async tasks and compensations [ INFO ] Unlocking existing entities [ INFO ] Checking the Engine database consistency [ INFO ] Stage: Transaction setup [ INFO ] DNF Repository copr:copr.fedorainfracloud.org:ovirt:ovirt-master-snapshot is listed more than once in the configuration [ INFO ] Stopping engine service [ INFO ] Stopping ovirt-fence-kdump-listener service [ INFO ] Stopping dwh service [ INFO ] Stopping vmconsole-proxy service [ INFO ] Stopping websocket-proxy service [ INFO ] Stage: Misc configuration (early) [ INFO ] Stage: Package installation [ INFO ] Stage: Misc configuration [ INFO ] Upgrading CA [ INFO ] Configuring WebSocket Proxy [ INFO ] Backing up database localhost:engine to '/var/lib/ovirt-engine/backups/engine-20260127180343.q9xj84af.dump'. [ INFO ] Creating/refreshing Engine database schema [ INFO ] Creating/refreshing DWH database schema [ INFO ] Updating OVN SSL configuration [ INFO ] Updating OVN timeout configuration [ INFO ] Creating/refreshing Engine 'internal' domain database schema Unregistering existing client registration info. Updating the engine FQDN in the Data Warehouse Database. [ INFO ] Generating post install configuration file '/etc/ovirt-engine-setup.conf.d/20-setup-ovirt-post.conf' [ INFO ] Stage: Transaction commit [ INFO ] Stage: Closing up --== SUMMARY ==-- [ INFO ] Starting dwh service [ INFO ] Starting Grafana service [ ERROR ] Failed to execute stage 'Closing up': Failed to start service 'grafana-server' [ INFO ] Stage: Clean up Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20260127180313-lps532.log [ INFO ] Generating answer file '/var/lib/ovirt-engine/setup/answers/20260127180410-setup.conf' [ INFO ] Stage: Pre-termination [ INFO ] Stage: Termination [ ERROR ] Execution of setup failed The log provided is so verbose that I can't spot the possible problem. I wonder, anyway, if this procedure is correct or whether I should do something different. For example I noticed that I am not asked to configure keycloak, since in the current production system I have freeipa. Thanks for the possible help, Andrea -- Andrea Chierici - INFN-CNAF Viale Berti Pichat 6/2, 40127 BOLOGNA Office Tel: +39 051 2095463 --

3 2

Q: VM Stuck in Powering Down Status
by Andrei Verovski 06 Feb '26

06 Feb '26

Hi, I have 1 VM which stuck in my ”Powering Down” status. This is what I did before in similar situations before: engine=# select vm_guid from vm_static where vm_name=‘My_VM-Active'; vm_guid -------------------------------------- f4e44168-92e2-40ec-a04e-c374ba2ef9b8 (1 row) engine=# select status from vm_dynamic where vm_guid='f4e44168-92e2-40ec-a04e-c374ba2ef9b8'; status -------- 16 (1 row) engine=# update vm_dynamic SET status=0 where vm_guid='f4e44168-92e2-40ec-a04e-c374ba2ef9b8'; UPDATE 1 engine=# update vm_dynamic SET run_on_vds=null WHERE vm_guid='f4e44168-92e2-40ec-a04e-c374ba2ef9b8'; UPDATE 1 But now this receipt doesn’t work. Running again engine=# select status from vm_dynamic where vm_guid='f4e44168-92e2-40ec-a04e-c374ba2ef9b8'; status -------- 16 (1 row) shows status didn’t changed. How to fix this ? Thanks in advance. Andrei

1 0

VM Template Reuse Between Clusters
by lmd＠gto.net 28 Jan '26

28 Jan '26

Good Morning! I recently added a second cluster to an oVirt environment and I am looking to re-use a number of templates between the clusters while providing self-service to users through the VM Portal. I would like to describe what I am seeing and ask whether you might know of what I am missing - or if you could share your experience. For sake of discussion, let us call the clusters "CORE" and "PROD" (the new cluster) and the template "UbuntuServer24". The template was created in cluster CORE against Storage Domain "CORE1". The template is visible to all users (role "UserTemplateBasedVm" for Everyone). CORE and PROD clusters contain the same networks and the hosts mount the same Storage Domains though, by policy, PROD cluster users are restricted to creating Disks only on Storage Domain "PROD1" through roles/permissions. User JDOE is a PROD cluster user, has VM Portal/"User role" rights to the cluster and Storage Domain and is able to deploy and manage VMs in Cluster PROD. JDOE is not intended to have any permissions against Cluster CORE. JDOE has temporary Admin Portal rights but I would prefer they operate through VM Portal at all times. Here is what I am seeing: Using the Administrator Portal, JDOE can deploy template UbuntuServer24 in PROD without any trouble. Using the VM Portal, using "Create Virtual Machine", JDOE does not see the "UbuntuServer24" template in the list of available templates. It appears to be filtered out of the list. Based on research so far, I can create a second copy of the template (ex: deploy a VM and capture a template in cluster PROD) as different name "UbuntuServer24-PROD". With no other changes, user JDOE can successfully deploy this new template into cluster PROD via VM Portal. I think this proves JDOE permissions and roles are in good shape. For testing I have also temporarily added equivalent permissions for JDOE against Cluster CORE and can confirm that the "UbuntuServer24" is only displayed as a Template when cluster "CORE" is selected as the target for the new VM in the "Create Virtual Machine" flow. The duplicated template approach does work but it means that there are two templates to offer the same result in each of the two clusters. I am concerned that this leaves an opportunity for de-sync, some additional storage consumption, and an enforced requirement for a different template name (string) which complicates user-facing documentation. Ideally I would like to maintain a single template to keep things simple and make it easy for other team members to use and maintain the environment. I tried to find a reference to my query in the docs as well as web search but didn't come up with something I was confident was on the right path. Is there a way to reuse templates between clusters in this manner and, if so, could you kindly please point me in the right direction? Thank you very much for any advice you may have, Dan Galway

1 0

Upgrading self-hosted engine from 4.5.6 on Stream 8
by Devin A. Bougie 27 Jan '26

27 Jan '26

Hi, All. If possible, I’d greatly appreciate an overview of the recommended procedure for upgrading a self-hosted engine setup from 4.5.6 on CentOS Stream release 8 to 4.5.7. All of our hosts are running fully-updated AlmaLinux 9. When we initially setup our cluster, this gave us a self-hosted engine running CentOS Stream release 8. As 8 is no-longer supported, it seems the first step for upgrading our cluster from 4.5.6 to 4.5.7 is to update the engine to Stream 9 (or 10)? Has anyone else completed this upgrade, and does this look like the right approach? 1. Put the cluster in global maintenance: hosted-engine --set-maintenance --mode=global 2. Stop ovirt-engine on the engine VM: systemctl stop ovirt-engine.service 3. Backup the engine: /usr/bin/engine-backup --mode=backup --scope=all --file="/var/lib/ovirt-engine-backup/backup.tar.bz2" --log=/var/log/ovirt-engine-backups.log 4. From an existing host, deploy a new engine: hosted-engine --deploy --restore-from-file=backup.tar.bz2 5. From the new engine, re-install each existing host. If that looks correct, is there anything we need to do for the existing hosts that are running many VMs in addition to the hosted engine? Should we expect to be able to deploy a new engine and update each host to 4.5.7 without downtime for any running VMs? Many thanks, Devin

3 3

Cannot logon cockpit for Ovirt 4.5.5
by Ethan Provensen 27 Jan '26

27 Jan '26

I am new to all of this. I recently downloaded the latest ISO, ovirt-node-ng-installer-latest-el9.iso, and I am trying to follow the directions. When I try to access cockpit on another PC with a GUI desktop and try to logon cockpit with root and the password I set for root when I created the server, it says wrong "Wrong user name or password". What user name should I be using to logon cockpit? All the the information I found, I am supposed to use root with the password I gave root when I created the oVirt server. What am I doing wrong?

3 2

oVirt Administration Portal will not load after upgrade to 4.5.7
by scottwilkins＠cicsnc.org 26 Jan '26

26 Jan '26

I'm running oVirt in standalone on a Centos Stream 9 box. The VM Portal will load fine, but the Admin Portal fails with a 500 error. When I dig down in the server log, the error message is: Caused by: java.lang.IllegalArgumentException: MigrationPolicies has no value for version: 4.8 When I run engine-config -g MigrationPolicies I get results for version 4.2 up to 4.7, but nothing for 4.8. Is this something I need to manually add? One other piece of confusing info is that the console still lists the version as 4.5.6-1.el9. I didn't see any errors during either the yum update or the engine-setup processes, but I may have missed something. Any help you all can give me would be great.

3 2

NmstateVerificationError
by Ivaan Reddy 26 Jan '26

26 Jan '26

ibnmstate.error.NmstateVerificationError: desired ======= --- name: bond0 type: bond state: up ipv4: enabled: false ipv6: enabled: false link-aggregation: mode: 802.3ad options: xmit_hash_policy: layer3+4 port: - ens30f1np1 - ens10f1np1 mac-address: 80:5B:7F:C2:1A:D6 mtu: 1500 current ======= --- name: bond0 type: bond state: up ipv4: enabled: false ipv6: enabled: false lldp: enabled: false difference ========== --- desired +++ current @@ -6,12 +6,5 @@ enabled: false ipv6: enabled: false -link-aggregation: - mode: 802.3ad - options: - xmit_hash_policy: layer3+4 - port: - ens30f1np1 - ens10f1np1 mac-address: 80:5B:7F:C2:1A:D6 -mtu: 1500 +lldp: + enabled: false Deployment failed with above error . I am using a Oracle 8.10 version ,kernel version - 5.15.0-315.196.5.2.e18uek.X86)64 and Broad com 100G NICS

1 0

CentOS Repo Disable for oVirt 4.5.7
by Deek Lee 22 Jan '26

22 Jan '26

Hi there, I'm upgrade my lab from oVirt 4.5.6 to oVirt 4.5.7 which has redhat 9.4 as base OS on the manager. When try to do dnf upgrade getting error on the dependency, is it safe to disable the CentOS repo on yum.repo... [root@chnrmzicsovmg01 ~]# mv /etc/yum.repos.d/ CentOS-Ceph-Pacific.repo CentOS-OpenStack-yoga.repo CentOS-Stream-Extras-common.repo CentOS-Gluster-10.repo CentOS-OpsTools.repo redhat.repo CentOS-Messaging-rabbitmq.repo CentOS-oVirt-4.5.repo CentOS-NFV-OpenvSwitch.repo CentOS-Storage-common.repo [root@chnrmzicsovmg01 ~]# mv /etc/yum.repos.d/CentOS-OpenStack-yoga.repo /etc/yum.repos.d/CentOS-OpenStack-yoga.repo.bkp [root@chnrmzicsovmg01 ~]# dnf update Updating Subscription Management repositories. Last metadata expiration check: 1:34:56 ago on Wednesday 21 January 2026 09:58:42 AM. Error: Problem 1: package centos-stream-release-9.0-26.el9.noarch from @System conflicts with system-release provided by redhat-release-9.7-0.7.el9.x86_64 from rhel-9-for-x86_64-baseos-rpms - cannot install the best update candidate for package redhat-release-9.5-0.6.el9.x86_64 - problem with installed package centos-stream-release-9.0-26.el9.noarch Problem 2: 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 - 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 the best update candidate for package python3-qpid-proton-0.35.0-2.el9s.x86_64 - problem with installed package python3-pyngus-2.3.0-8.el9s.noarch Problem 3: 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-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 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 - package python3-oslo-messaging-12.13.3-1.el9s.noarch from @System requires python3-pyngus, but none of the providers can be installed - cannot install the best update candidate for package qpid-proton-c-0.35.0-2.el9s.x86_64 - problem with installed 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)

1 0

oVirt 4.5.7 is now generally available
by Jean-Louis Dupond 20 Jan '26

20 Jan '26

*oVirt 4.5.7 is now generally available* The oVirt Project is pleased to announce the availability of the 4.5.7 release as of January 13 2026. oVirt is a free open-source distributed virtualization solution, designed to manage your entire enterprise infrastructure. oVirt uses the trusted KVM hypervisor and is built upon several other community projects, including libvirt, Gluster, PatternFly, and Ansible. This release is now available on x86_64 architecture for: oVirt Node NG (based on CentOS Stream 9) CentOS Stream 9 CentOS Stream 10 RHEL 9 and derivatives RHEL 10 and derivatives To everyone using the oVirt Node NG we urge you to switch over to another way of using the product for ensured stability and security due to the way of how that product is structured. To find out how to interact with oVirt developers and users and ask questions, visit our community page. All issues or bugs should be reported via oVirt GitHub. If you’d like to try oVirt as quickly as possible, follow the instructions on the Download page. For complete installation, administration, and usage instructions, see the oVirt Documentation. For a general overview of oVirt, read the About oVirt page. To learn about features introduced before 4.5.7, see the release notes for previous versions. IMPORTANT If you are going to install on RHEL or derivatives please follow Installing on RHEL first. NOTE It is important that for installs on RHEL 10 and derivates that version 10.0-4 (or newer) of centos-release-ovirt45 is used. What’s New in 4.5.7? New releases in 4.5.7 Contributors New cpu’s What’s New in 4.5.7? CentOS 10 and AlmaLinux 10 support. Fixed CVE-2024-7259 Introduced new CPU’s Bumped external dependencies. Implemented new way of deploying to maven central. All Java code is now built on Java 21 and compatible with Java 11. Reconnect faster to host after reboot, instead of static 10 minutes adapted to connect when host is back online. On boot of VM have a spare of NumOfPciExpressPorts PCIe ports available instead of a fixed number. Add the optional attach_wgt flag to the vm start endpoint. This will auto attach the virtio-win iso to the vm. Ability to add tags to templates via UI in the administration panel. Add operating system description to host api object. Added option for user to decide preference of vnc console invocation. Added Windows 2025 and RHEL 10 to OS list. Improve isLiveDelete check on VM. Dropped deprecated packages. Dropped Ceph, Cinderlib and collectd in Centos 10 due to not available. Added new DC/Cluster level (4.8). Cluster level 4.8 now uses pc-q35-rhel9.6.0 machine type and enables discard-no-unref by default. Added ability to alter video device through API. Set audio value to ich9 starting from rhel7 on Q35. When a VDS network error occurs during VM start, set the VM status to “Unknown” instead of letting it fall through to “Down”. This to prevent duplicate VM deployments. Ability to update QoS on running VM’s when a QoS profile has been modified or when QoS was changed on a vNIC profile Many more changes were implemented in the newest releases of the oVirt packages and can be read about in detail down below. New releases in 4.5.7 ovirt-engine-4.5.7 cockpit-ovirt-0.16.3 ovirt-hosted-engine-setup-2.7.2 ovirt-node-ng-4.4.3 ovirt-engine-extension-aaa-ldap-1.5.0 otopi-1.10.5 ovirt-engine-ui-extensions-1.3.8-1 imgbased-1.2.26 ovirt-engine-metrics-1.6.3 ovirt-engine-extension-aaa-jdbc-1.3.1 ovirt-engine-keycloak-15.0.2-7 engine-db-query-1.6.5 ovirt-host-4.5.1-1 ovirt-engine-extensions-api-1.0.2 ovirt-log-collector-4.5.1 ovirt-engine-extension-aaa-misc-1.1.2 ovirt-dependencies-4.5.7 ovirt-setup-lib-1.3.4 ovirt-engine-build-dependencies-4.5.7 ovirt-web-ui 1.9.4 vdsm v4.50.6.1 vdsm-jsonrpc-java v1.7.4 python-ovirt-engine-sdk4 4.6.3 ovirt-engine-api-metamodel 1.3.11 ovirt-engine-api-model 4.6.1 ovirt-ansible-collection 3.2.1 ovirt-dwh 4.5.10 ovirt-hosted-engine-ha v2.5.2 mom 0.6.5 ovirt-engine-sdk-ruby 4.6.1 ovirt-engine-sdk-java 4.6.0 ovirt-provider-ovn 1.2.36 ovirt-engine-nodejs-modules 2.3.21 ovirt-vmconsole 10.0.10 terraform-provider-ovirt v2.2.0 ovirt-engine-sdk 4.5.1 ioprocess v1.4.3 userstorage 0.5.3 ovirt-tinycore-linux v13.13 ovirt-engine-wildfly 24.0.1-3 ovirt-jboss-modules-maven-plugin 2.0.4 Contributors 33 people contributed to this release: Arthur Verschaeve (Contributed to: ovirt-site) Artur Socha (Contributed to: vdsm-jsonrpc-java) Brian King (Contributed to: mom) Brooklyn Dewolf (Contributed to: vdsm) Eli Marcus (Contributed to: ovirt-site) Frank Wall (Contributed to: ovirt-site) Geoff O’Callaghan (Contributed to: ovirt-site, ovirt-node-ng-image, ovirt-appliance) Jasper Berton (Contributed to: ovirt-engine, vdsm, ovirt-web-ui, ovirt-engine-sdk, ovirt-site, cockpit-ovirt, ovirt-engine-sdk-java, mom, ovirt-engine-sdk-ruby, ovirt-provider-ovn, ovirt-engine-api-model, ovirt-hosted-engine-setup, python-ovirt-engine-sdk4, ovirt-engine-sdk-go, java-client-kubevirt, ovirt-engine-extension-aaa-ldap, ovirt-engine-api-metamodel, ovirt-engine-ui-extensions, imgbased, ovirt-engine-metrics, releng-tools, ovirt-engine-extension-aaa-jdbc, ovirt-engine-keycloak, ovirt-hosted-engine-ha, engine-db-query, ovirt-cockpit-sso, ovirt-lldp-labeler, ovirt-engine-extensions-api, ovirt-log-collector, ovirt-engine-nodejs-modules, ovirt-engine-extension-aaa-misc, ovirt-jboss-modules-maven-plugin, ovirt-dependencies, ovirt-setup-lib, ovirt-engine-build-dependencies) Jean-Louis Dupond (Contributed to: ovirt-engine, vdsm, terraform-provider-ovirt, ovirt-web-ui, ovirt-engine-sdk, ovirt-ansible-collection, cockpit-ovirt, ovirt-engine-sdk-java, ovirt-node-ng-image, ovirt-appliance, ovirt-imageio, mom, ovirt-engine-sdk-ruby, ovirt-provider-ovn, ovirt-engine-api-model, ovirt-hosted-engine-setup, python-ovirt-engine-sdk4, ovirt-engine-sdk-go, ovirt-system-tests, java-client-kubevirt, ovirt-engine-extension-aaa-ldap, otopi, vdsm-jsonrpc-java, ovirt-engine-api-metamodel, ovirt-engine-ui-extensions, imgbased, ovirt-release, ovirt-openvswitch, ovirt-engine-metrics, ovirt-vmconsole, ovirt-engine-extension-aaa-jdbc, ovirt-dwh, ovirt-engine-keycloak, ost-images, ovirt-hosted-engine-ha, engine-db-query, ovirt-cockpit-sso, ioprocess, buildcontainer, ovirt-engine-extensions-api, ovirt-log-collector, ovirt-engine-nodejs-modules, ovirt-engine-extension-aaa-misc, ovirt-jboss-modules-maven-plugin, ovirt-dependencies, ovirt-engine-wildfly, ovirt-setup-lib, userstorage, ovirt-tinycore-linux, ovirt-resources-upload-action, ovirt-build-dependencies, ovirt-engine-build-dependencies) Anton (Contributed to: ovirt-imageio) Jiri Slezka (Contributed to: ovirt-engine) Joschokvc (Contributed to: ovirt-engine-extension-aaa-jdbc) José Enrique Gutiérrez Mazón (Contributed to: vdsm) Juan Hernandez (Contributed to: ovirt-engine-sdk-ruby, ovirt-engine-api-metamodel) Keenan Brock (Contributed to: ovirt-engine-sdk-ruby) Lev Veyde (Contributed to: ovirt-site) Marc Dequènes (Duck) (Contributed to: ovirt-site) Marcin Sobczyk (Contributed to: vdsm, ovirt-system-tests, ovirt-vmconsole, ost-images) Martin Necas (Contributed to: ovirt-ansible-collection) Martin Perina (Contributed to: ovirt-engine-extension-aaa-ldap, ovirt-engine-extension-aaa-misc) Maxime Besson (Contributed to: terraform-provider-ovirt) Michael Trapp (Contributed to: vdsm) Michalskrivanek (Contributed to: ovirt-node-ng-image, ovirt-appliance, ovirt-system-tests) Peter Boden (Contributed to: ovirt-engine, vdsm, ovirt-ansible-collection, ovirt-provider-ovn, ovirt-engine-api-model, ovirt-system-tests, otopi, vdsm-jsonrpc-java, ovirt-vmconsole, releng-tools, ovirt-dwh, ost-images, ovirt-tinycore-linux, ovirt-engine-build-dependencies) Puhamihai (Contributed to: terraform-provider-ovirt) Raaghav Wadhawan (Contributed to: ovirt-engine) Sandro Bonazzola (Contributed to: ovirt-site, 512-byte-vm, ovirt-node-ng-image, ovirt-engine-sdk-ruby, python-ovirt-engine-sdk4, ovirt-system-tests, ovirt-engine-api-metamodel, imgbased, ovirt-release, ovirt-dwh, ost-images, ovirt-host, ioprocess, safelease, upload-rpms-action, checkout-action, ovirt-engine-build-dependencies) Sergii Kuzko (Contributed to: vdsm) Shubhaoracle (Contributed to: vdsm, ovirt-ansible-collection) Stanislav Melnichuk (Contributed to: ovirt-engine, ovirt-dwh, ovirt-engine-extension-aaa-misc, ovirt-engine-build-dependencies) Tomáš Golembiovský (Contributed to: mom) Vic Demuzere (Contributed to: ovirt-engine-sdk-go) Yedidyah Bar David (Contributed to: ovirt-dwh) New cpu’s Intel: Sapphire Rapids Server Secure Sapphire Rapids Server (all security features mentioned in v2 on qemu) AMD: EPYC Milan Secure EPYC Milan (all security features mentioned in v2 on qemu) EPYC Rome EPYC Rome v2 (all features mentioned in v2 on qemu) EPYC Genoa IBM: POWER10

3 3

oVirt 4.5.7 upgrade guide for RHEL8 systems
by Kapetanakis Giannis 20 Jan '26

20 Jan '26

oVirt 4.5.7 release is definitely good news and kudos to the devs behind this release. Can we have a documentation ideally on https://www.ovirt.org/documentation/upgrade_guide/ or at least in the mailing list for the upgrade path from RHEL8 (and derivatives) and 4.5.6 to 4.5.7 on newer OS? I see on release notes that only RHEL9+ is supported for both engine and hosts. Our systems, both standalone engine as well as hosts are all on Rocky 8. Will a backup of engine, install of 4.5.7 on new OS and restore from backup will be able to see and manage the non-upgraded RHEL8 hosts? Maybe upgrade the hosts first and the engine later? What is the recommended way of making the upgrade? On more question: RHEL10 does not see v2 hosts. Alma does support them. Are there v2 binaries released for RHEL10 systems (engine and hosts) or should we stick to RHEL9. Thanks, Giannis

1 0

oVirt thick client Python+QT6 - any interest?
by John Boero 17 Jan '26

17 Jan '26

Hi I've been a longtime fan of oVirt since my Red Hat days. I was just playing around with vibe coding a thick client in Python + QT6 to give oVirt the app I think it always deserved. Results are early but pretty slick actually. Is anybody interested in pulling this into the GH org and developing further? An early beta after about 2 hours of playing can be found here: https://github.com/jboero/ovirt_client John Boero

1 0

Unable to install oVirt on RHEL7.5
by SS00514758＠techmahindra.com 15 Jan '26

15 Jan '26

Hi All, I am unable to install oVirt on RHEL7.5, to install it I am taking reference of below link, https://www.ovirt.org/documentation/install-guide/chap-Installing_oVirt.html But though it is not working for me, couple of dependencies is not getting installed, and because of this I am not able to run the ovirt-engine, below are the depencies packages that unable to install, Error: Package: collectd-write_http-5.8.0-6.1.el7.x86_64 (@ovirt-4.2-centos-opstools) Requires: collectd(x86-64) = 5.8.0-6.1.el7 Removing: collectd-5.8.0-6.1.el7.x86_64 (@ovirt-4.2-centos-opstools) collectd(x86-64) = 5.8.0-6.1.el7 Updated By: collectd-5.8.1-1.el7.x86_64 (epel) collectd(x86-64) = 5.8.1-1.el7 Available: collectd-5.7.2-1.el7.x86_64 (ovirt-4.2-centos-opstools) collectd(x86-64) = 5.7.2-1.el7 Available: collectd-5.7.2-3.el7.x86_64 (ovirt-4.2-centos-opstools) collectd(x86-64) = 5.7.2-3.el7 Available: collectd-5.8.0-2.el7.x86_64 (ovirt-4.2-centos-opstools) collectd(x86-64) = 5.8.0-2.el7 Available: collectd-5.8.0-3.el7.x86_64 (ovirt-4.2-centos-opstools) collectd(x86-64) = 5.8.0-3.el7 Available: collectd-5.8.0-5.el7.x86_64 (ovirt-4.2-centos-opstools) collectd(x86-64) = 5.8.0-5.el7 Help me to install this. Looking forward to resolve this issue. Regards Sumit Sahay

8 10

Offline installation - is is possible?
by postecom＠gmail.com 15 Jan '26

15 Jan '26

I have been looking at oVirt for a while. My current virtualization is an older version of RHV. With RHV, I could have my hypervisors completely isolated from the internet and all updates come through Red Hat's Satellite. Is is possible to add the installation repos as a product in Satellite? It is very important that the hypervisors not have access to the Internet, but all the documentation and installation info that I can find wants the hypervisors to use the COPR plugin and have direct access to centos stream. Thank you

7 9

install el10 host with ovirt45-testing
by Jiří Sléžka 02 Jan '26

02 Jan '26

Hi, I am testing host installation from ovirt45-testing repo. I choose Alma Linux 10 for it as it still support Spice. Engine runs also 4.5.7 but on Rocky Linux 9. Other hosts are Rocky Linux 8. First small glitch is that after yum install centos-release-ovirt45-testing the repo centos-ovirt45-testing is disabled by default. I did not mention it and try to create new host witch failed early in Install stage (playbook can't find ovirt packages). I know it is not typical problem but in this case I ended up with host stucked in Install stage and cannot switch it to maintenance and/or remove it. I had to do it directly in db. Second try was without problems but after I set-up network I ended in Non operational mode because "Host does not comply with the cluster emulated machine. The cluster emulated machine is pc-i440fx-rhel7.6.0;pc-q35-rhel8.6.0 and the host emulated machines are pc-q35-rhel9.6.0,pc-q35-rhel9.4.0,q35,pc-q35-rhel9.2.0,pc-q35-rhel9.0.0,pc-q35-rhel10.0.0,pc,pc-i440fx-rhel10.0.0." As I read list archives I could try "Reset Emulated Machine" in Cluster menu. Current emulated machine type is pc-q35-rhel8.6.0. One odd thing is that "Clusters hosts must be down in order to perform this action." which leads me to question whether it is safe or possible in my current mix of el8 and el10 hosts. Cheers, Jiri

2 1