Matt Churchyard wrote:

> As I understand it
> 1) shutdown from guest
> 2) 'kill <pid>' -> pressing the power button once.
> 3) --force-poweroff -> holding power button in
> 4) --force-reset -> pressing the reset button
> 5) bhyvectl --destroy -> same as 3? (although vmm is destroyed as well)
> 1 or 2 are obviously preferred. I've found however that some guests don't 
> respond that well to the apci event. CentOS 6 seems to need apci installing 
> and enabling?!, and my Win2012R2 machine will only shutdown if I send the 
> signal twice.
> The rest are all hard shutdowns that should not be seen as a way to stop the 
> guest, just a last resort if it can't be stopped correctly. I don't know the 
> practical difference between poweroff&destroy vs just destroy.

I CCed Peter and Neel, probably they'll shed some light on 'bhyvectl
--force-poweroff && bhyvectl --destroy' vs just 'bhyvectl --destroy'.

> I see no reason why the documentation suggests reboot rather than shutdown. 
> Bhyve exits either way and the only difference is the exit code. When using 
> one of the bhyve management tools that support reboots (such as 
> however, a "restart" exit code (0) will cause the 
> guest to restart automatically; If a guest is locked up for example, a 
> --force-reset will cause it to immediately reboot.
> From a host, the only safe choice is 'kill <pid>' (possibly multiple times) 
> and wait for bhyve process to (hopefully) exit. If that doesn't work either 
> the acpi issue needs fixing or ideally the guest needs to be stopped using 
> its built-in shutdown function.
> The devs will have to confirm why they're implemented the way they are. My 
> instinct is that bhyvectl works on the vmm device, and reset/poweroff are 
> just functions that are possible via that interface, and so have been 
> exposed. The ACPI shutdown event likely needs to be initiated by the bhyve 
> process itself, hence using a signal to it. /end-speculation
> I think most users will want to use a bhyve tool so the raw specifics of the 
> bhyve/bhyvectl commands are glossed over, although that doesn't mean the 
> handbook documentation of the base commands shouldn't be as complete/correct 
> as possible of course.

FWIW, I've created a patch:

which at least documents exit codes and the SIGTERM thing.

Roman Bogorodskiy

Attachment: signature.asc
Description: PGP signature

Reply via email to