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

[Hollis Blanchard <hollisb@us.ibm.com>]

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)?

-- 
Hollis Blanchard
IBM Linux Technology Center