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

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.

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.

-- Jamie


Reply via email to