[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