[Qemu-devel] Re: [libvirt] Re: [PATCH 2/3] Introduce monitor 'wait' command
Anthony Liguori
anthony at codemonkey.ws
Wed Apr 8 19:35:44 UTC 2009
Jamie Lokier wrote:
> Anthony Liguori wrote:
>
>> It doesn't. When an app enables events, we would start queuing them,
>> but if it didn't consume them in a timely manner (or at all), we would
>> start leaking memory badly.
>>
>> We want to be robust even in the face of poorly written management
>> apps/scripts so we need some expiration function too.
>>
>
> What happens when an app stops reading the monitor channel for a
> little while, and there's enough monitor output to fill TCP buffers or
> terminal buffers? Does it block QEMU? Does QEMU drop arbitrary bytes
> from the stream, corrupting the output syntax?
>
Depends on the type of character device. They all have different
properties in this regard. Basically, you're stuck in a losing
proposition. Either you drop output, buffer memory indefinitely, or put
the application to sleep. Different character devices make different
trade offs.
> If you send events only to the monitor which requests them, then you
> could say that they are sent immediately to that monitor, and if the
> app stops reading the monitor, whatever normally happens when it stops
> reading happens to these events.
>
> In other words, no need for arbitrary expiration time. Makes it
> determinstic at least.
>
You're basically saying that if something isn't connected, drop them.
If it is connected, do a monitor_printf() such that you're never queuing
events. Entirely reasonable and I've considered it.
However, I do like the idea though of QEMU queuing events for a certain
period of time. Not everyone always has something connected to a
monitor. I may notice that my NFS server (which runs in a VM) is not
responding, VNC to the system, switch to the monitor, and take a look at
the event log. If I can get the past 10 minutes of events, I may see
something useful like a host IO failure.
>> Monitor "sessions" are ill-defined
>> though b/c of things like tcp:// reconnects so I wouldn't want to do that.
>>
>
> Oh dear. Is defining it insurmountable?
>
> Why can't each TCP (re)connection be a new monitor?
>
You get a notification on reconnect but not on disconnect. Basically
CharDriverState is not designed around a connect model. The fact that
it has any notion of reconnect today is really a big hack.
CharDriverState could definitely use a rewrite. It hasn't aged well at all.
Regards,
Anthony Liguori
More information about the libvir-list
mailing list