Bug 237479 - sysutils/vm-bhyve: need a more robust "vm stopall"
Summary: sysutils/vm-bhyve: need a more robust "vm stopall"
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs mailing list
URL:
Keywords: bhyve, feature
Depends on:
Blocks:
 
Reported: 2019-04-23 02:52 UTC by Victor Sudakov
Modified: 2019-04-30 01:41 UTC (History)
5 users (show)

See Also:
bugzilla: maintainer-feedback? (churchers)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Victor Sudakov 2019-04-23 02:52:11 UTC
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.
Comment 1 Rodney W. Grimes freebsd_committer 2019-04-23 03:56:14 UTC
(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.
Comment 2 paul vixie 2019-04-23 12:04:23 UTC
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.
Comment 3 Jason Barbier 2019-04-23 14:00:59 UTC
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.
Comment 4 Victor Sudakov 2019-04-30 01:41:42 UTC
(In reply to Jason Barbier from comment #3)
Who knows if "save machine state" will be supported in bhyve one day?