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

[Luiz Capitulino <lcapitulino@redhat.com>]

On Tue, 09 Mar 2010 17:55:41 -0600
Anthony Liguori <anthony@codemonkey.ws> wrote:

> 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?

 Well, maybe we need to define a criteria for what should be an
event and what shouldn't then? Or what should be done by QEMU and
what should be done by the management tool?

 Also, would be good to hear from management tool people (that's
usually libvirt people) what they think about doing this kind of
thing by polling.

 That said, we can't do that for this specific case as explained by
Kevin.

> 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