The "/usr/local/etc/rc.d/vm stop" script calls "vm stopall". If some VM would not stop, this can delay the system shutdown procedure for too log while vm-bhyve is waiting for all pids. We need some logic that would poweroff a VM if it does not ACPI-stop within a configured grace period.
(In reply to Victor Sudakov from comment #0) I would like to see some enhancements in a few aspects of this request, for one the idea of an ordered shutdown of the vm's given a list, but not a reverse list of /etc/rc.conf vm_list would be useful. ESXi does this, but they get it wrong in that the list is infact just the reverse of the startup, and that has many issues. I see good use for the "kill them with ACPI shutdown, then wait N seconds, then reap them with a harder signal" as useful. I would also like to understand why we repeat the killall that is there now.
i don't think time is the problem. the client might be waiting on hardware i/o, for example dumping a lot of user-mode data. the best logic would be something like reboot.c does, wait a few seconds, then wait up to one minute if the client is still showing i/o activity.
Yes, we need to do something here, but I do agree with Paul here. we need to do something more robust here first. as the host we have no way of knowing what IO is important and if we prematurely kill a guest it could be disastrous for the guest.
(In reply to Jason Barbier from comment #3) Who knows if "save machine state" will be supported in bhyve one day?