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

[Luiz Capitulino <lcapitulino@redhat.com>]

On Wed, 23 May 2012 11:35:42 +0100
"Daniel P. Berrange" <berrange@redhat.com> wrote:

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

Ok, and thinking about it again that's something we could add later on if
needed.

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

Okay, that's reasonable to me. The balloon event is just a hint then (as events
are supposed to be) and it does reflect the balloon state in the VM at the time
it's emitted.

I'd have to review the series in more detail, but in principle seems good.

Anthony, do you have objections?