Re: [Qemu-devel] [PATCH] Add event notification for guest balloon changes

["Daniel P. Berrange" <berrange@redhat.com>]

On Mon, May 21, 2012 at 04:44:38PM +0530, Amit Shah wrote:
> On (Thu) 17 May 2012 [08:49:44], Daniel P. Berrange wrote:
> > On Wed, May 16, 2012 at 01:58:34PM -0500, Anthony Liguori wrote:
> > > On 05/16/2012 01:42 PM, Luiz Capitulino wrote:
> > > >On Wed, 16 May 2012 11:10:47 +0100
> > > >"Daniel P. Berrange"<berrange@redhat.com>  wrote:
> > > >
> > > >>From: "Daniel P. Berrange"<berrange@redhat.com>
> > > >>
> > > >>After setting a balloon target value, applications have to
> > > >>continually poll 'query-balloon' to determine whether the
> > > >>guest has reacted to this request. The virtio-balloon backend
> > > >>knows exactly when the guest has reacted though, and thus it
> > > >>is possible to emit a JSON event to tell the mgmt application
> > > >>whenever the guest balloon changes.
> > > >>
> > > >>This introduces a new 'qemu_balloon_change()' API which is
> > > >>to be called by balloon driver backends, whenever they have
> > > >>a change in balloon value. This takes the 'actual' balloon
> > > >>value, as would be found in the BalloonInfo struct.
> > > >>
> > > >>The qemu_balloon_change API emits a JSON monitor event which
> > > >>looks like:
> > > >>
> > > >>   {"timestamp": {"seconds": 1337162462, "microseconds": 814521},
> > > >>    "event": "BALLOON_CHANGE", "data": {"actual": 944766976}}
> > > >
> > > >It's missing an entry in QMP/qmp-events.txt and I have a comment below,
> > > >but in general looks good.
> > > >
> > > >Amit, would be good to get your ack.
> > > 
> > > I think it would be safer to limit this event to (1) only firing
> > > once target has been reached (2) firing if target is deviated from
> > > without a corresponding change in target.
> > > 
> > > Otherwise, a guest could just flood libvirt with events.  This would
> > > queue memory in QEMU indefinitely as the events got queued up to
> > > potentially serving as a DoS against other guests.
> > 
> > Hmm, that's a good point, but my concern was that if we only emit
> > the event when the target is reached, what happens if the guest
> > gets very close to the target but never actually reaches it for
> > some reason.
> > 
> > Should we perhaps just rate limit it to once per second ?
> 
> This also has a slight disadvantage of missing to send out a
> notification if it was received within the 1-second window, but no
> further events come from the guest.

No, it would not (and indeed must not) miss any events. In the worst
case it would delay delivery of an event by upto 1 second, if an
identical event had already been sent within the last second.

eg it would work as follows

 1. First event arrives at time 250ms. Send it immediately

 2. Second event arrives at time 300ms. Already had an event 50ms
    ago. Do not send this event. Set 1 second timer.

 3. Third event arrives at time 400ms. A timer is pending. Do not
    send this event. Discard 2nd event.

 4. Fourth event arrives at time 500ms. A timer is pending. Do not
    send this event. Discard 3rd event.

 5. Timer fires at time 1300ms. Send fourth event

If the 5th event arrives before time 2300ms, we repeat the timer
delay process, otherwise we can send it immediately.

So after every 1 second window we can *guarantee* that the app
has received the most recent event from that time window.

> Overall, the qmp emitter itself could gain a new API to rate-limit
> events, if so configured.

Not all event types can be automatically rate-limited. Throttling
the RTC CHANGE or BALLOON CHANGE events is fine, because an appliction
only ever cares about the current value. Throttling SPICE CONNECT /
DISCONNECT events can cause trouble because there is stateful info
associated with each event that mustbe tracked by the application.


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