Hello,
Some follow-up:
I watched for shutdown events and it seems OpenBSD is not receiving ACPI
signals.
I looked at my other OpenBSD guests, they also are not receiving these
ACPI signals
and are not shutting down cleanly. I will have to investigate again to
see if my Linux
VMs are receiving these signals or not. What I see is my other OpenBSD
VMs recover
just fine, but my one VM needs an fsck due to an sqlite file. My
assumption is that
OpenBSD is doing what it should, but bhyve is not sending the signal,
for whatever
reason. I have the right flags set (the defaults) in OpenBSD to respond
to ACPI
signals properly.
Courtney
On 7/3/25 6:36 AM, Dave Voutila wrote:
Lloyd <ng2...@proton.me> writes:
Courtney wrote:
SmartOS host on the bhyve hypervisor. Yes, it will do this and pull the
plug. The guest gets quite a bit of time to poweroff. For some reason,
it seems that only my Vaultwarden guest wants to take long. I also have
a more complex synapse server and OpenBao server running which shut down
in time. I don't know if there is a way to extend that timeout on the
host, but I also don't like that solution as much if it does exist.
https://smartos.org/man/8/vmadm
stop <uuid> [-F] [-t timeout]
| For HVM VMs, the running qemu/bhyve process sends an ACPI signal to the
| guest kernel telling it to shut down. In case the guest kernel ignores
| this or for some reason does not receive this request we mark the VM
| with a transition property indicating that we tried to shut it down.
| This transition marker also includes a timeout (default 180 seconds).
| If we hit the timeout, the VM is forcibly halted.
I would dig through syslogs to find out if your VM is even receiving the
ACPI shutdown command. Under Hyper-V I would see something like this:
messages:Jun 16 12:06:30 fortress /bsd: Shutting down in response to request
from hyperv0 host
I generally agree with this. I believe bhyve supports ACPI power events,
but I vaguely remember bhyve devs only recently improving this in the
past few years. I'm not a bhyve user...nor a illumos/SmartOS user...so
no idea what level of support is implemented.
The better question is why your VM is taking > 3 minutes to shut down.
I'd suggest having serial console access and keeping an eye on what the
guest is doing in terms of dmesg output. I'd look at what rc scripts may
be taking forever to stop their respective daemon. This feels like a
userland issue.
