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"<berra...@redhat.com> wrote: > > > > > >>From: "Daniel P. Berrange"<berra...@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. Overall, the qmp emitter itself could gain a new API to rate-limit events, if so configured. Amit