[Qemu-devel] Re: [libvirt] Re: [PATCH 2/3] Introduce monitor 'wait' command
hollisb at us.ibm.com
Wed Apr 8 21:31:34 UTC 2009
On Wed, 2009-04-08 at 16:14 -0500, Anthony Liguori wrote:
> Hollis Blanchard wrote:
> > On Wed, 2009-04-08 at 14:35 -0500, Anthony Liguori wrote:
> >> 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.
> > "10 minutes" is the red flag for me. Why not 5 minutes? 60 minutes? 24
> > hours? The fact that it's so arbitrary suggests it doesn't really
> > belong. If you care, you can attach a logging daemon that keeps the last
> > 10 minutes worth of data...
> 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.
If the socket will buffer it, why do you *also* want to buffer in qemu
(adding code and complexity)?
IBM Linux Technology Center
More information about the libvir-list