[vm-bhyve] Windows 2012 and 2016 servers guests would not stop

[Matt Churchyard]

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 at freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to "freebsd-virtualization-unsubscribe at freebsd.org"