Re: [Qemu-devel] Re: [libvirt] Re: [PATCH 2/3] Introduce monitor 'wait' command
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