From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LrfJj-0006tN-TC
	for qemu-devel@nongnu.org; Wed, 08 Apr 2009 17:28:19 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LrfJf-0006t3-9K
	for qemu-devel@nongnu.org; Wed, 08 Apr 2009 17:28:19 -0400
Received: from [199.232.76.173] (port=46099 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LrfJf-0006t0-46
	for qemu-devel@nongnu.org; Wed, 08 Apr 2009 17:28:15 -0400
Received: from mx2.redhat.com ([66.187.237.31]:35413)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <zamsden@redhat.com>) id 1LrfJd-0001sa-Pf
	for qemu-devel@nongnu.org; Wed, 08 Apr 2009 17:28:14 -0400
Message-ID: <49DD16D1.9060006@redhat.com>
Date: Wed, 08 Apr 2009 11:27:45 -1000
From: Zachary Amsden <zamsden@redhat.com>
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>
In-Reply-To: <49DCFC90.8070805@codemonkey.ws>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: libvir-list@redhat.com, Jan Kiszka <jan.kiszka@web.de>, qemu-devel@nongnu.org, Hollis Blanchard <hollisb@us.ibm.com>

Anthony Liguori wrote:

> 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.

If you want finite and deterministic behavior, the only way to achieve
it is by using a finite number of events.  Even better, you can
pre-allocate the events themselves in a large array avoiding runtime
memory operations and just use them as a ring.  The fixed number of
monitor events could be a command line or config option.  And if no
monitor has connected since overflow, deliberately corrupt the first event.

(qemu) wait
monitor warning !!Message buffer has overflowed=Event log truncated!!