The Thursday 28 Aug 2014 à 13:36:35 (+0100), Stefan Hajnoczi wrote : > On Wed, Aug 27, 2014 at 04:58:12PM +0200, Anshul Makkar wrote: > > I am writing a block IO latency tracker. > > > > As obvious, I am calculating the latency by tracking the interval between > > start of IO and end of IO. > > (firing my latency tracker from function BlockDriverAIOCB *raw_aio_submit() > > raw-posix.c when job is submitted). > > > > The latency data per QEMU process will be written to shared memory and then > > another app uses this shared memory to read the data. That's a simple > > architecture. > > > > Can't use "info blockstats" QMP command as qmp socket is used and blocked > > by some other process in our subsystem. > > > > Just want a suggestion whether my approach is correct given the constraint > > that I can't use qmp socket or if any alternative is possible. > > Simplest option: use iostat(1) inside the guest. > > Or you can use tracing tools to measure block I/O request latency. > > An example from a few years ago: > http://www.linux-kvm.org/page/Virtio/Block/Latency > > It depends what you are trying to achieve.
Stefan: ProfitBrick is a cloud provider. This means they could prepare AMI (Virtual machine images) with stuff in it but they never would access the shell of a running VM. What happen in the guest after the AMI instanciation into a running VM is the end user business and the cloud provider should not violate the end user territory. I also agree that having QEMU collecting latencies statistics would be very useful. Best regards Benoît > > Stefan
