Re: [Qemu-devel] Re: [libvirt] Re: [PATCH 2/3] Introduce monitor 'wait' command

[Anthony Liguori <anthony@codemonkey.ws>]

Paul Brook wrote:
>> It has to be some finite amount.   You're right, it's arbitrary, but so
>> is every other memory limitation we have in QEMU.  You could make it
>> user configurable but that's just punting the problem.
>>
>> You have to do some level of buffering.  It's unavoidable.  If you
>> aren't buffering at the event level, you buffer at the socket level, etc.
>>     
>
> No you don't. If you use event flags rather than discrete events then you 
> don't need to buffer at all. You just need to be able to store the state of 
> each type of event you're going to raise, which should be a bounded set.
>
> This has its own set of issues - typically race conditions or "lost" events if 
> the client (libvirt) code isn't written carefully, and means you can't attach 
> information with an event, only indicate that something happened.
> However if the correct model is used (event driven polling rather than purely 
> event driven) this shouldn't be problem.
>   

It's just deferring the problem.  Consider the case of VNC user 
authentication.  You want to have events associated with whenever a user 
connects and disconnects so you can keep track of who's been on a 
virtual machine for security purposes.

In my model, you record the last 10 minutes worth of events.  If a user 
aggressively connects/reconnects, you could consume a huge amount of 
memory.  You could further limit it by recording only a finite number of 
events to combat that problem.

In your model, the VNC server triggers a user-connected event and a 
user-disconnected event.  This bits are constantly reset which is fine.  
When libvirt gets around to seeing the events, it know wants to know 
who's been connecting/disconnecting.

Either you show only the current user, which is not terribly useful, or 
you have the VNC server queue a list of the most recent user 
connects/disconnects.  The problem with this model is that by pushing 
the queuing to the event generators, you end open up the possibility 
that someone is going to get something wrong.  It's just more places to 
do it poorly.

Regards,

Anthony Liguori

> Paul
>