> 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
