From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ld1hF-0001OT-DJ for qemu-devel@nongnu.org; Fri, 27 Feb 2009 07:20:05 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ld1hA-0001L9-7I for qemu-devel@nongnu.org; Fri, 27 Feb 2009 07:20:04 -0500 Received: from [199.232.76.173] (port=39001 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ld1hA-0001L6-2c for qemu-devel@nongnu.org; Fri, 27 Feb 2009 07:20:00 -0500 Received: from mx20.gnu.org ([199.232.41.8]:53465) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Ld1h9-0008MN-Sq for qemu-devel@nongnu.org; Fri, 27 Feb 2009 07:19:59 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ld1h8-0006gt-F3 for qemu-devel@nongnu.org; Fri, 27 Feb 2009 07:19:58 -0500 From: Paul Brook Subject: Re: [Qemu-devel] Hardware watchdogs (patch for discussion only) Date: Fri, 27 Feb 2009 12:19:53 +0000 References: <20090225233718.GA15750@amd.home.annexia.org> <20090226175025.GA10284@shareable.org> <1235728224.5894.176.camel@ecrins.fosdick.home.net> In-Reply-To: <1235728224.5894.176.camel@ecrins.fosdick.home.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902271219.54657.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Steve Fosdick On Friday 27 February 2009, Steve Fosdick wrote: > On Thu, 2009-02-26 at 17:50 +0000, Jamie Lokier wrote: > > For real continuity of service you'd also want QEMU itself to have a > > watchdog. Either a software watchdog internally (SIGALRM => kill/exec > > self, or child process expecting regular pings over a pipe), or by > > QEMU itself becoming a client of the host watchdog. > > So many possibilities - one, two, or three watchdogs? IMHO external watchdog (i.e. ones that monitor qemu itself) are out of scope. We should restrict this to internal watchdog devices within a VM. There already exist several solutions for external fencing. Traditionally these are used in a clustered environment, where physical machines are connected to remote power switches (or equivalent management cards). Making these system kill/restart virtual machines seems like it should be a very minor tweak. Paul