In the related code this looks like:
834 if (info.size_arg > info.allocation)
835 virBufferAddLit(&buf, "preallocation=metadata,");
836 else
837 virBufferAddLit(&buf, "preallocation=falloc,");
And size_arg == capacity (from xml).
Per definition [1] we have three cases for "allocation":
a) allocation can be bigger than capacity for high-metadata overhead cases
b) If allocation is omitted when creating a volume, the volume will be fully allocated at time of
creation.
c) If set to a value smaller than the capacity, the pool has the option of deciding to sparsely
allocate a volume.
But as we see in the XMLs above virt-manager asks to fully allocate. We hit neither of (a)/(b).
Therefore the pool has -NOT- the option to do a sparse allocation as we also do not hit (c)
It isn't written/defined explicitly in those statements, but our case of capacity==allocation should (form the text) behave like (b) at least in my reading. It didn't do so in the past and the libvirt change [2] fixed that unclarity.
I don't think we'd want to change libvirt to go back to not allocate in this case.
But we should report and ask at virt-manager if it should/want to submit a smaller allocation 0<=allocation<=capacity to get back to the old behavior.
virt-manager upstream then has a chance to agree and fix it (which we would backport) or discuss pointing to a different reading of [1] that would end up in a libvirt discussion and fix then.
With the older (pre 4.3) libvirt in place this creates it with metadata preallocation.
/usr/bin/qemu-img create -f qcow2 -o preallocation= metadata, compat= 1.1,lazy_ refcounts /var/lib/ libvirt/ images/ ubuntu18. 04.qcow2 15728640K
In the related code this looks like: (&buf, "preallocation= metadata, "); (&buf, "preallocation= falloc, ");
834 if (info.size_arg > info.allocation)
835 virBufferAddLit
836 else
837 virBufferAddLit
And size_arg == capacity (from xml).
Per definition [1] we have three cases for "allocation":
a) allocation can be bigger than capacity for high-metadata overhead cases
b) If allocation is omitted when creating a volume, the volume will be fully allocated at time of
creation.
c) If set to a value smaller than the capacity, the pool has the option of deciding to sparsely
allocate a volume.
But as we see in the XMLs above virt-manager asks to fully allocate. We hit neither of (a)/(b).
Therefore the pool has -NOT- the option to do a sparse allocation as we also do not hit (c)
It isn't written/defined explicitly in those statements, but our case of capacity= =allocation should (form the text) behave like (b) at least in my reading. It didn't do so in the past and the libvirt change [2] fixed that unclarity.
I don't think we'd want to change libvirt to go back to not allocate in this case. =capacity to get back to the old behavior.
But we should report and ask at virt-manager if it should/want to submit a smaller allocation 0<=allocation<
virt-manager upstream then has a chance to agree and fix it (which we would backport) or discuss pointing to a different reading of [1] that would end up in a libvirt discussion and fix then.
[1]: https:/ /libvirt. org/formatstora ge.html# StorageVol /libvirt. org/git/ ?p=libvirt. git;a=commit; h=c9ec7088c7a3f 4cd26bb471f1f24 3931fff6f4f9
[2]: https:/