[libvirt] [PATCH v5 1/2] conf, docs: Add qcow2 cache configuration support

[Liu Qing]

On Mon, Sep 18, 2017 at 09:49:36AM -0400, John Ferlan wrote:
> 
> 
> On 09/14/2017 01:08 AM, Liu Qing wrote:
> > Random write IOPS will drop dramatically if qcow2 l2 cache could not
> > cover the whole disk. This patch gives libvirt user a chance to adjust
> > the qcow2 cache configuration.
> > 
> > Three new qcow2 driver parameters (l2-cache-size, refcount-cache-size
> > and cache-clean-interval) are added as attributes to a new <qcow2>
> > subelement for a <driver name='qemu' type='qcow2'...> of a <disk>
> > element. The QEMU source docs/qcow2-cache.txt provides the guidelines
> > for defining/configuring values for each.
> > 
> > Signed-off-by: Liu Qing <liuqing at huayun.com>
> > ---
> >  docs/formatdomain.html.in                          | 41 +++++++++
> >  docs/schemas/domaincommon.rng                      | 35 ++++++++
> >  src/conf/domain_conf.c                             | 96 ++++++++++++++++++++--
> >  src/qemu/qemu_driver.c                             |  5 ++
> >  src/util/virstoragefile.c                          |  3 +
> >  src/util/virstoragefile.h                          |  6 ++
> >  .../qemuxml2argv-disk-drive-qcow2-cache.xml        | 43 ++++++++++
> >  .../qemuxml2xmlout-disk-drive-qcow2-cache.xml      | 43 ++++++++++
> >  tests/qemuxml2xmltest.c                            |  1 +
> >  9 files changed, 268 insertions(+), 5 deletions(-)
> >  create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-qcow2-cache.xml
> >  create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-drive-qcow2-cache.xml
> > 
> 
> OK - so I had my head in other code during the v4 review comments from
> Peter. So I'll just "restart" that a bit here. If I can summarize the
> comments... There's a concern that we're creating a very specific set of
> parameters for which there isn't great guidance available other than
> going to a source file in the qemu tree and attempting to decipher it.
> Something I did note at one time as a possible issue and why I also
> asked for the "qcow2" subelement. It makes it painfully obvious that
> there was something very specific. I figure seeing a "qcow2" element
> name would fairly easily point out to anyone that specificity.
> 
> So, based on what I read in the responses it seems that the purpose of
> the values is to provide a mechanism to "allow" qemu to use a couple of
> different algorithms to perform operations, but qemu wants the user to
> decide whether they are willing to sacrifice one thing over another. If
> you want high IOPS, then you have to sacrifice something else; whereas,
> if you don't care about performance, then you sacrifice something else.
> 
> In any case, I think what could be useful is to determine if there is a
> way to "automate" something such that the "dials" would be automatically
> set based on the algorithms. That is - rather than supplying the
> specific values, supply a named attribute that would then perform the
> calculations and set the values, such as "high_performance="yes" or
> "large_capacity=yes". Where you cannot set both, but can set one or the
> other.  Or can you set both? Is there value in partially turning a knob?
>  If so maybe the attribute is "performance={default, ..., best}" and
> "capacity={default, ..., large}". Then based on the value of the
> attribute, code you add to libvirt would perform the calculations.
> 
> Or do you really think that's something some supplier (such as what
> you're trying to do) would want to have - the ability to control the
> algorithm for the various knobs.
I googled the qcow2 cache and there are already some discussion about
how to give a user friendly interface, even in the qemu community.
https://bugzilla.redhat.com/show_bug.cgi?id=1377735
I don't what to involve this, as this is hard to lead to an all win
result. A high level policy configuration would be enough for us.
If a policy configuration on libvirt level is necessary, I think a new patch
could be made. For example adding new attribute in the <qcow2 .../> element
which controls how the cache is automatically configured. But this may lead to
another discussion about what's a good policy. A policy way and the knob
way could both be available on libvirt level.