qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] wake-on-lan & IPMI implementation; real power-off and -


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] wake-on-lan & IPMI implementation; real power-off and -no-shutdown
Date: Tue, 16 Mar 2010 17:44:55 +0000
User-agent: Mutt/1.4.1i

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]