Re: [Qemu-devel] [PATCH 0/3]: BLOCK_WATERMARK QMP event

[Anthony Liguori <anthony@codemonkey.ws>]

On 03/09/2010 05:25 PM, Luiz Capitulino wrote:
>   Also note that this applies for other events and if this becomes the
> standard mode of operation, the end result is that we're delegating
> event generation for the management tools.
>    

We will end up with hundreds of events if we implement this sort of 
thing for every management tool.

There's a significant difference between a VNC connect event and a "high 
watermark" event.

A client connects and disconnects relatively infrequently.  They are 
absolute events and are likely to trigger some action.  A management 
tool could poll but generally speaking, generating a notification has 
wide valid.

A "high watermark" event is an event that occurs because one statistic 
that we track hit a very simple condition: stat > THRESHOLD.  But as the 
commit message alludes to, why is stat > THRESHOLD interesting and stat 
< THRESHOLD not interesting?

Moreover, why isn't SUM(stat[0..n]) > THRESHOLD not the truly 
interesting event?  It's because in this instance, a very specific 
management tool happens to implement a heuristic based on stat > 
THRESHOLD.  However, a different management tool is likely to implement 
a significantly different heuristic.  This isn't limited to the block 
device.

A good example is the recent balloon statistics information.  We're 
implementing a daemon that periodically polls the balloon driver using a 
rather sophisticated set of conditions to take actions.  You could make 
the same argument that we should push those heuristics into QEMU which 
would mean that daemon wouldn't need to exist.

Management tools are going to have to poll statistics from QEMU to 
implement heuristics.  It's not something we can hide in events.

Regards,

Anthony Liguori