[libvirt] [PATCH 12/12] getstats: start crawling backing chain for qemu

Peter Krempa pkrempa at redhat.com
Mon Dec 8 14:47:19 UTC 2014


On 12/06/14 09:14, Eric Blake wrote:
> Wire up backing chain recursion.  Note that for now, we just use
> the same allocation numbers for read-only backing files as what
> offline domains would report.  It is not the correct allocation
> number for qcow2 over block devices during block-commit, and it
> misses out on the fact that qemu also reports read statistics on
> backing files that are worth knowing about (seriously - for a
> thin-provisioned setup, it would be nice to easily get at a count
> of how many reads were serviced from the backing file in relation
> to reads serviced by the active layer).  But it is at least
> sufficient to prove that the algorithm is working, and to let
> other people start coding to the interface while waiting for
> later patches that get the correct information.

Is that a proof-of-concept then? I'd like to avoid adding stats fields
that will change, especially this close to the release as we're running
into the risk of baking it in.

> 
> For a running domain, where one of the two images has a backing
> file, I see the traditional output:
> 
> $ virsh domstats --block testvm2
> Domain: 'testvm2'
>   block.count=2
>   block.0.name=vda
>   block.0.path=/tmp/wrapper.qcow2
>   block.0.rd.reqs=1
>   block.0.rd.bytes=512
>   block.0.rd.times=28858
>   block.0.wr.reqs=0
>   block.0.wr.bytes=0
>   block.0.wr.times=0
>   block.0.fl.reqs=0
>   block.0.fl.times=0
>   block.0.allocation=0
>   block.0.capacity=1310720000
>   block.0.physical=200704
>   block.1.name=vdb
>   block.1.path=/dev/sda7
>   block.1.rd.reqs=0
>   block.1.rd.bytes=0
>   block.1.rd.times=0
>   block.1.wr.reqs=0
>   block.1.wr.bytes=0
>   block.1.wr.times=0
>   block.1.fl.reqs=0
>   block.1.fl.times=0
>   block.1.allocation=0
>   block.1.capacity=1310720000
> 
> vs. the new output:
> 
> $ virsh domstats --block --backing testvm2
> Domain: 'testvm2'
>   block.count=3
>   block.0.name=vda
>   block.0.path=/tmp/wrapper.qcow2
>   block.0.rd.reqs=1
>   block.0.rd.bytes=512
>   block.0.rd.times=28858
>   block.0.wr.reqs=0
>   block.0.wr.bytes=0
>   block.0.wr.times=0
>   block.0.fl.reqs=0
>   block.0.fl.times=0
>   block.0.allocation=0
>   block.0.capacity=1310720000
>   block.0.physical=200704
>   block.1.name=vda
>   block.1.path=/dev/sda6
>   block.1.backingIndex=1
>   block.1.allocation=1073741824
>   block.1.capacity=1310720000
>   block.1.physical=1073741824
>   block.2.name=vdb
>   block.2.path=/dev/sda7
>   block.2.rd.reqs=0
>   block.2.rd.bytes=0
>   block.2.rd.times=0
>   block.2.wr.reqs=0
>   block.2.wr.bytes=0
>   block.2.wr.times=0
>   block.2.fl.reqs=0
>   block.2.fl.times=0
>   block.2.allocation=0
>   block.2.capacity=1310720000

ACK to the idea of the stat output idea ...

> 
> * src/qemu/qemu_driver.c (QEMU_DOMAIN_STATS_BACKING): New internal
> enum bit.
> (qemuConnectGetAllDomainStats): Recognize new user flag, and pass
> details to...
> (qemuDomainGetStatsBlock): ...here, where we can do longer recursion.
> (qemuDomainGetStatsOneBlock): Output new field.
> 
> Signed-off-by: Eric Blake <eblake at redhat.com>
> ---
>  src/qemu/qemu_driver.c | 55 +++++++++++++++++++++++++++++++++++++++++---------
>  1 file changed, 46 insertions(+), 9 deletions(-)
> 

.. but we shouldn't add code that reports wrong data.

Peter



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20141208/1664bfa6/attachment-0001.sig>


More information about the libvir-list mailing list