Victor Sudakov wrote on 2019-04-22 19:43:
...
>> And the implementation is pretty brutal:
>> # 'vm stopall'
>> # stop all bhyve instances
>> # note this will also stop instances not started by vm-bhyve #
>> core::stopall(){
>> local _pids=$(pgrep -f 'bhyve:')
>>
>> echo "Shutting down all bhyve virtual machines"
>> killall bhyve
>> sleep 1
>> killall bhyve
>> wait_for_pids ${_pids}
>> }
> yow.
>>
>> I wonder what the effect of the second kill is, that seems odd.
>
> Indeed.
> the first killall will cause each client OS to see a soft shutdown signal.
> the sleep 1 gives them some time to flush their buffers. the second killall
> says, time's up, just stop.
Both of these killall commands send a soft shutdown signal and I've never seen
an instance in my own testing where the second has caused an instant poweroff.
I've just double checked this, and a FreeBSD guest stopped with the existing
code fully shuts itself down, ending with "acpi0: Powering system off"
The main reason for having both is that in my initial testing, I could not get
Windows to respond to a single SIGINT. 100% of the time it would simply act
like nothing had happened. Sending two however triggered a shutdown. I only
have a single test machine though so maybe it's something strange about my
particular system that no one else experiences...
Matt
> i think this is worse than brutal, it's wrong. consider freebsd's own work
> flow when trying to comply with the first soft shutdown it got:
> https://github.com/freebsd/freebsd/blob/master/sbin/reboot/reboot.c#L220
> this has bitten me more than once, because using "pageins" as a proxy for "my
> server processes are busy trying to synchronize their user mode state" is
> inaccurate. i think _any_ continuing I/O should > be reason to wait the full
> 60 seconds.
> and so i think the "sleep 1" above should be a "sleep 65".
> What is needed in vm-bhyve is the feature that if ACPI does not stop
> the guest for a predefined period of time, the guest is powered off.
> i agree with this.
--
> P Vixie
_______________________________________________
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virtualization-unsubscr...@freebsd.org"
_______________________________________________
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virtualization-unsubscr...@freebsd.org"
