[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH] Add event notification for guest balloon changes
Date: Thu, 17 May 2012 16:20:42 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 05/17/2012 07:56 AM, Luiz Capitulino wrote:
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.

libvirt certainly would have to maintain a timeout and make a decision on what to do if the guest doesn't balloon to target. Not sure how having events help at all here.

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.

No, VNC clients are a whole different ballgame. VNC connections will only happen from the management network, we don't worry about memory allocation from malicious VNC clients.


Anthony Liguori

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]