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