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

[Anthony Liguori <anthony@codemonkey.ws>]

On 05/17/2012 07:56 AM, Luiz Capitulino wrote:
> On Thu, 17 May 2012 08:49:44 +0100
> "Daniel P. Berrange"<berrange@redhat.com>  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.
>
> 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.

Regards,

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