Re: [Qemu-devel] block IO latency tracker without using QMP socket.

[Markus Armbruster]

Benoît Canet <address@hidden> writes:

> The Wednesday 27 Aug 2014 à 16:58:12 (+0200), Anshul Makkar wrote :
>> Hi,
>> 
>> 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).
>
> Are you sure that your user want to measure latency in this place.
> In fact there is a lot of work done before requests reach raw-posix.c so
> the numbers you have may be smaller than the reality.

Yes.  Whether the difference is significant I can't say without
measuring it.

> In QEMU IO statistics are collected near the guest in the block device model
> so the statitics are close to what the guest would measure.

The I/O stats collecting code needs work, though.

>> 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.
>
> Why not simply writting periodically a json report (qemu has code to write 
> json)
> into a char device (pipe, tcp socket etc) QEMU support (Markus's idea) ?
>
>> 
>> Can't use "info blockstats" QMP command as qmp socket is used and blocked
>> by some other process in our subsystem.
>
> Libvirt can work as a proxy to passthrough simple QMP commands to QEMU.

Thus, libvirt doesn't really "block" its QMP socket.

> I think this approach is better than having two different programs 
> manipulating
> separate QMP sockets because only one program really accessing QMP
> means coherency
> can be enforced.

You can have multiple QMP monitors.  Manipulating state on a secondary
monitor behind the management application's back can get you in trouble,
as Benoît said.  But if all you do with a secondary monitor is query
information, you should be fine.

> For example libvirt or the program acting as a proxy could whitelist QMP 
> methods
> that are safe to use and do not risk to confuse libvirt state machine.
> (Preventing of modifying QEMU state in libvirt's back)
>
>> 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.

I think the existing interfaces should suffice to get stats out.  If
not, generally useful improvements are welcome.  One off hacks won't
help the next guy with a similar problem.