Re: [Qemu-devel] [PATCH v2 0/3] Event notifications for balloon driver

[Daniel P. Berrange]

On Tue, May 22, 2012 at 05:55:30PM -0300, Luiz Capitulino wrote:
> On Mon, 21 May 2012 17:59:50 +0100
> "Daniel P. Berrange" <address@hidden> wrote:
> 
> > This series is a followup to 2 previously posted patches
> > 
> >  * BALLOON_CHANGE QMP event:
> >    http://lists.nongnu.org/archive/html/qemu-devel/2012-05/msg02215.html
> > 
> >  * query-events QMP command: 
> >    http://lists.nongnu.org/archive/html/qemu-devel/2012-05/msg02255.html
> > 
> > Changes since v1:
> > 
> >  - Use a static array of strings for QMP event ID -> string conversion
> >  - Add BALLOON_CHANGE to qmp-events.txt
> > 
> > There is also a new patch in this series, which introduces the ability
> > todo simple rate limiting of stateless monitor events. With the ballooning
> > of a 1.8 GB guest, down to 0.9 GB this reduced the number of events
> > emitted from ~50 down to just 4, spread across a 4 second time window.
> 
> How would that be with a 1TB guest?

Sure it would take longer but I don't see that as a problem, provided
the updates are not too frequent, which rate limiting ensures.

> One way of solving this would be to move the policy to the mngt app. that is,
> we could have a qmp-event-set-rate-limit command that could be allowed to
> be run while in negotiation mode (ie. before qmp_capabilities is executed).

Yep, I considered doing this, but to be honest I don't think we need that
kind of granularity. Even if we had this command, we'd just unconditionally
set the rate limit to 1 second & be done with it.

> But I'm honestly not sure if rate limit is the best solution for this 
> problem...
> How can several events spread in several seconds be useful to libvirt?

Basically at any point in time, libvirt wants to know what the current
balloon value is. We don't care whether it has "completed" or not, because
given a malicious guest it is entirely likely that completion may never
come, or indeed it may never balloon at all. Thus all we care about is
what the current value is, mgmt apps can then decide how/whether to enforce
this by setting cgroup limits.  Even without event notifications, all
libvirt cares about is the current level, as queried by 'query-balloon',
not any kind of completion. So the fact that events are progressively
spread over several seconds is in fact entirely desirable to us. THis
simply means we can avoid running 'query-balloon' and always have the
current balloon value accurate to approx 1 second.

> IMO, the best would be to have a way to know when the balloon driver is done
> servicing a balloon request.

As inferred above, IMHO, focusing on completion of ballooning is a bad
thing todo. Apps should only ever care about what the current balloon
level is.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|