On Thu, 17 May 2012 16:20:42 -0500 Anthony Liguori <anth...@codemonkey.ws> wrote:
> >> 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. I meant that if there's a way to detect the last balloon change, then that's the time we could emit BALLOON_CHANGE (vs. emitting only when the target is reached). I don't think the timeout is a bad idea, though. > >> 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. That's true, but as far as an event floods are concerned, I'm not completely sure we should trust the management network. But that was only an example, I think that the SUSPENDED event could also be used by a malicious guests the way Daniel describes above.
