The problem with sparse qcow2 images is that the Gluster shard xlator might not cope with the random I/O nature of the workload, as it will have to create a lot of shards in a short period of time ( 64MB shard size) for a small I/O ( for example 50 x 512 byte I/O request could cause 50 shards to be created simulatenously ). With VDO enabled, preallocated disk images will take a fraction of the size , but qcow2 metadata and gluster metadata (shard files) will exist and that problem should not exist at all. Can you try to reproduce the bug with Gluster v9.1 ? If it exists, let's create a separate thread in the gluster mailing list. Best Regards,Strahil Nikolov for most safety, you create a new gluster layout and storage domain, and slowly migrate the VM into new domain. If you do other workaround, you should test it very carefully beforehand. _______________________________________________ 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/VDMDZZ6TCT5XL5...