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.
