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 -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list