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

[Amit Shah <amit.shah@redhat.com>]

On (Mon) 21 May 2012 [12:29:52], Daniel P. Berrange wrote:
> 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.

(Yes, I just meant to note that such care should be taken.)

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

Of course, I mentioned we need a new API for that.

		Amit