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

[Luiz Capitulino]

On Thu, 17 May 2012 08:49:44 +0100
"Daniel P. Berrange" <address@hidden> 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"<address@hidden>  wrote:
> > >
> > >>From: "Daniel P. Berrange"<address@hidden>
> > >>
> > >>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.

Having a way to detect the last balloon change would be perfect.

> Should we perhaps just rate limit it to once per second ?
> 
> BTW, if we're considering guest initiated events to be a potential
> DOS in this way, then I should point out the RTC_CHANGE event
> will already suffer this way, if a malicious guest continually
> adjusts its hardware close. So we might want to apply rate limiting
> to that event too ?

I think several events can suffer from that. For example, a VNC
client could repeatedly connect & disconnect from QEMU. If we're going
to fix this, then we'd need a general solution for it.

But I think the balloon case is different, because we're not fighting
malicious guests/clients, it's really the balloon operation that can
cause the flood.