The referenced bug[1] was fixed in 4.4.9, the workarounds mentioned are to use web admin or API to create the disks [1] https://bugzilla.redhat.com/show_bug.cgi?id=1957830 On Thu, Feb 17, 2022 at 1:06 PM <nicolas@devels.es> wrote:
Hi,
We're using oVirt 4.4.8.6. We make an intensive use of the VM portal because we've hundreds of students creating their own VMs. Recently, one of the professors reported that they are encountering an error when adding a disk to a newly created VM.
They are creating ISO based VMs (CentOS-8-Stream in this case), everything goes smoothly but when adding a thin-provisioned disk, this error shows up:
2022-02-17 09:56:28,073Z INFO [org.ovirt.engine.core.bll.storage.disk.AddDiskCommand] (default task-39078) [0332e7b6-80b1-48e9-b849-80698f2ce7ab] Lock Acquired to object 'EngineLock:{exclusiveLocks='[e4a02ab9-31e4-4e8c-8999-91700263ff08=VM_DISK_BOOT]', sharedLocks='[e4a02ab9-31e4-4e8c-8999-91700263ff08=VM]'}' 2022-02-17 09:56:28,446Z WARN [org.ovirt.engine.core.bll.storage.disk.AddDiskCommand] (default task-39078) [0332e7b6-80b1-48e9-b849-80698f2ce7ab] Validation of action 'AddDisk' failed for user aluX@domain-authz. Reasons: VAR__ACTION__ADD,VAR__TYPE__DISK,ACTION_TYPE_FAILED_DISK_CONFIGURATION_NOT_SUPPORTED,$volumeFormat RAW,$volumeType Sparse,$backup None 2022-02-17 09:56:28,446Z INFO [org.ovirt.engine.core.bll.storage.disk.AddDiskCommand] (default task-39078) [0332e7b6-80b1-48e9-b849-80698f2ce7ab] Lock freed to object 'EngineLock:{exclusiveLocks='[e4a02ab9-31e4-4e8c-8999-91700263ff08=VM_DISK_BOOT]', sharedLocks='[e4a02ab9-31e4-4e8c-8999-91700263ff08=VM]'}' 2022-02-17 09:56:28,504Z ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-39078) [] Operation Failed: [Cannot add Virtual Disk. Disk configuration (RAW Sparse backup-None) is incompatible with the storage domain type.]
However, changing the provisioning to thick does work and the disk can be added.
I found [1] which talks about this but I'm not sure if it's the same issue, nor it has a solution yet.
Is this a known bug? Does it have any workaround beyond creating thick-provisioned disks?
Thanks.
Nicolás
[1]: https://access.redhat.com/solutions/6022811 _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-leave@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/users@ovirt.org/message/OPGUDWMDPHWTTT...