[libvirt PATCH 1/2] storage: add support for QCOW2 cluster_size option

Pavel Hrdina phrdina at redhat.com
Wed May 19 16:23:02 UTC 2021


On Wed, May 19, 2021 at 02:49:14PM +0200, Peter Krempa wrote:
> On Thu, May 13, 2021 at 13:23:04 +0200, Pavel Hrdina wrote:
> > The default value hard-coded in QEMU (64KiB) is not always the ideal.
> > Having a possibility to set the cluster_size by user may in specific
> > use-cases improve performance for QCOW2 images.
> > 
> > QEMU internally has some limits, the value has to be between 512B and
> > 2048KiB and must by power of two, except when the image has Extended L2
> > Entries the minimal value has to be 16KiB.
> > 
> > Since qemu-img ensures the value is correct and the limit is not always
> > the same libvirt will not duplicate any of these checks as the error
> > message from qemu-img is good enough:
> > 
> >     Cluster size must be a power of two between 512 and 2048k
> > 
> > Resolves: https://gitlab.com/libvirt/libvirt/-/issues/154
> > 
> > Signed-off-by: Pavel Hrdina <phrdina at redhat.com>
> > ---
> 
> [...]
> 
> > @@ -867,6 +868,11 @@
> >          the file image is used in VM. To create non-raw file images, it
> >          requires QEMU version since 2.1. <span class="since">Since 1.2.7</span>
> >        </dd>
> > +      <dt><code>clusterSize</code></dt>
> > +      <dd> Changes the qcow2 cluster size where smaller size can improve image
> > +        file size whereas larger size can improve performance.
> > +        <span class="since">Since 7.4.0</span>
> 
> I think we should refrain from advice on how the cluster size can be
> configured because it has way more nuance than this short sentence.

Reasonable, I can drop it as I was just rephrasing what qemu has in
their documentation.

> > +      </dd>
> >        <dt><code>features</code></dt>
> >        <dd>Format-specific features. Only used for <code>qcow2</code> now.
> >          Valid sub-elements are:
> 
> 
> 
> > diff --git a/tests/storagevolxml2xmlin/vol-qcow2-clusterSize.xml b/tests/storagevolxml2xmlin/vol-qcow2-clusterSize.xml
> > new file mode 100644
> > index 0000000000..22534982a1
> > --- /dev/null
> > +++ b/tests/storagevolxml2xmlin/vol-qcow2-clusterSize.xml
> > @@ -0,0 +1,17 @@
> > +<volume>
> > +  <name>OtherDemo.img</name>
> > +  <key>/var/lib/libvirt/images/OtherDemo.img</key>
> > +  <capacity unit="G">5</capacity>
> > +  <allocation>294912</allocation>
> > +  <target>
> > +    <path>/var/lib/libvirt/images/OtherDemo.img</path>
> > +    <format type='qcow2'/>
> 
> I wonder whether it wouldn't make more sense to stash cluster size under
> the 'format' tag.
> 
> Does the LVM volume XML have <format> ?

No it doesn't have it. Only for pool XML. In addition currently it has
only path attribute.

For qcow2 we have most of the options represented outside the <format>
element. I'm not saying it's correct as I cannot decide which place
would be better, but following what we already do with other qcow2
options I figured we should do the same here.

It is definitely possible to have it in <format>.

Pavel

> > +    <permissions>
> > +      <mode>0644</mode>
> > +      <owner>0</owner>
> > +      <group>0</group>
> > +      <label>unconfined_u:object_r:virt_image_t:s0</label>
> > +    </permissions>
> > +    <clusterSize unit='KiB'>128</clusterSize>
> > +  </target>
> > +</volume>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20210519/c324ca33/attachment-0001.sig>


More information about the libvir-list mailing list