From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NrapH-0001nd-KN for qemu-devel@nongnu.org; Tue, 16 Mar 2010 13:45:07 -0400 Received: from [199.232.76.173] (port=58519 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NrapH-0001n8-2G for qemu-devel@nongnu.org; Tue, 16 Mar 2010 13:45:07 -0400 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NrapE-0004xw-MP for qemu-devel@nongnu.org; Tue, 16 Mar 2010 13:45:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:63737) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NrapE-0004xo-7b for qemu-devel@nongnu.org; Tue, 16 Mar 2010 13:45:04 -0400 Date: Tue, 16 Mar 2010 17:44:55 +0000 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] wake-on-lan & IPMI implementation; real power-off and -no-shutdown Message-ID: <20100316174455.GP23617@redhat.com> References: <2378452091-BeMail@laptop> <20100315155526.GV26239@redhat.com> <4B9E6059.3040400@codemonkey.ws> <20100316172851.GB19160@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100316172851.GB19160@shareable.org> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: =?utf-8?B?RnJhbsOnb2lz?= Revol , qemu-devel@nongnu.org On Tue, Mar 16, 2010 at 05:28:51PM +0000, Jamie Lokier wrote: > > The semantics of -no-shutdown are awful. > > > > I'd personally prefer to see the option deprecated and a new set of > > options introduced with clearer semantics. > > > > Currently, -no-shutdown does too many things. It affects reboot > > behaviour, shutdown behaviour, the behavior of the SDL close button. > > Each of these things should be individual tunables. > > I'm not sure about -no-shutdown, but I've had some problems with -no-reboot, > which I use for semi-automated OS installations. > > I use -no-reboot so that when the guest does a reboot during > installation, as they invariably do one or more times, QEMU exits, my > scripts does things eject the CD/floppy, or change it for the next in > sequence, and modify the guest's installed files to add virtio > drivers, install extra fiels, edit boot scripts and whatever else is > useful, and then restart QEMU. > > The guest thinks it's just rebooted, but it has the virtualisation > goodies in place to run better. That's the way libvirt / virt-manager does provisioning too. > Unfortunately with an MS-DOS 5.00 guest, -no-reboot does not > work. It fails to exit QEMU; instead it just reboots. I guess that > means a QJSON event would not be sent either. > > For my use case, it would be even better if guest reboot paused the > guest and sent a QJSON event instead of having to use -no-reboot. > Then I wouldn't have to close and restart the VNC client repeatedly > during installs. That would be nice! > Now that we have ways to choose what kind of events and actions are > triggered by the QEMU watchdog device, it would be nice to fit guest > reboot (perhaps even the different types of reboot) / host-forced > reboot / guest powerdown / host-forced powerdown (like holding down > the power button for 5 seconds on a real PC) into the same/similar > framework as the watchdog, with same/similar event types and action > choices. Agreed, it'd be good to have a more generalized method of controlling the lifecycle actions in QEMU. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|