From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lrf6s-0000xS-6z for qemu-devel@nongnu.org; Wed, 08 Apr 2009 17:15:02 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lrf6n-0000ux-7J for qemu-devel@nongnu.org; Wed, 08 Apr 2009 17:15:01 -0400 Received: from [199.232.76.173] (port=38056 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lrf6n-0000uu-3X for qemu-devel@nongnu.org; Wed, 08 Apr 2009 17:14:57 -0400 Received: from rv-out-0708.google.com ([209.85.198.240]:53585) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lrf6m-0000W4-Ph for qemu-devel@nongnu.org; Wed, 08 Apr 2009 17:14:56 -0400 Received: by rv-out-0708.google.com with SMTP id l33so246986rvb.22 for ; Wed, 08 Apr 2009 14:14:55 -0700 (PDT) Message-ID: <49DD13CA.5050209@codemonkey.ws> Date: Wed, 08 Apr 2009 16:14:50 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [libvirt] Re: [PATCH 2/3] Introduce monitor 'wait' command References: <1239200204-4934-1-git-send-email-aliguori@us.ibm.com> <1239200204-4934-2-git-send-email-aliguori@us.ibm.com> <20090408143335.GS18076@redhat.com> <49DCBCBE.6010102@redhat.com> <49DCE266.9080809@us.ibm.com> <20090408190611.GC10947@shareable.org> <49DCFC90.8070805@codemonkey.ws> <1239222488.21926.39.camel@slate.austin.ibm.com> In-Reply-To: <1239222488.21926.39.camel@slate.austin.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hollis Blanchard Cc: libvir-list@redhat.com, Jan Kiszka , qemu-devel@nongnu.org, Gerd Hoffmann 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. Regards, Anthony Liguori