Date: Mon, 22 Apr 2019 22:18:28 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: Paul Vixie <paul@redbarn.org> Cc: Victor Sudakov <vas@mpeks.tomsk.su>, freebsd-virtualization@freebsd.org Subject: Re: [vm-bhyve] Windows 2012 and 2016 servers guests would not stop Message-ID: <201904230518.x3N5IS8J036033@gndrsh.dnsmgr.net> In-Reply-To: <d33ea04e-4f4f-253a-b658-e6ecfd2308a6@redbarn.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
>
> 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
Interesting, more interesting would be to dig out the
path that the system takes when it gets teh ACPI shutdown
event. That is not going to end up in sbin/reboot is it?
Doesnt that run from within init itself?
I find in the init man page this:
The init utility will terminate all possible processes (again, it will
not wait for deadlocked processes) and reboot the machine if sent the
interrupt (INT) signal, i.e. ``kill -INT 1''. This is useful for
shutting the machine down cleanly from inside the kernel or from X when
the machine appears to be hung.
So my guess is that sending an ACPI shutdown event to the VM ends up
sending a -INT to init. Looking inside init, it seems to end up
execing a shell runing /etc/rc.shutdown.
I do not know if the ACPI event is then blocked in the kernel so
the second one is pointless, but I believe once we enter into
-INT processing that signal is ignored, so infact this second
signal is actaully OK. But I am not 100% sure on this, yet.
> 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".
I think the sleep and the second signal are near pointless. If
we have a race in ACPI processing we need to fix that.
> > 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.
There is a PR up,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237479
please add comments there if you feel so inclined.
> --
> P Vixie
--
Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201904230518.x3N5IS8J036033>