Date: Tue, 23 Apr 2019 09:43:01 +0700 From: Victor Sudakov <vas@mpeks.tomsk.su> To: freebsd-virtualization@freebsd.org Subject: Re: [vm-bhyve] Windows 2012 and 2016 servers guests would not stop Message-ID: <20190423024301.GA940@admin.sibptus.ru> In-Reply-To: <201904211708.x3LH8DiK028282@gndrsh.dnsmgr.net> References: <20190421154616.GA59283@admin.sibptus.ru> <201904211708.x3LH8DiK028282@gndrsh.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
Rodney W. Grimes wrote:
[dd]
> > > That is more likely your problem in that your sending these acpi
> > > shutdown requests one at a time, and they should be broadcast in
> > > the "power going out" case.
> >
> > Whence is the idea that "vm stopall" does a sequential shutdown? What sense
> > would that make?
>
> Well I am not sure that vm-bhyve does this, but esxi certainly does,
> and it is a royal PITA to deal with sometimes. It does make sense
> in some aspects, do not want the database server going offline before
> all the clients go down do we? Kinda makes for a bunch of nonsense
> errors logged due to missing server. I kinda like my virtual routers
> and firewalls to keep going tell the end too.
>
> This is all YMMV situations though.
OK, you have convinced me, a predictable sequential shutdown may make
sense sometimes. Anyway, it's not there im vm-bhyve so it's not the
reason for the slow shutdown.
>
> > A sequential startup does make sense but a sequential shutdown? Useless
> > I think. The man page says that
>
> For you perhaps useless, but that rarely rules out that there may be
> a totally valid and usefull case.
>
> > stopall
> > Stop all running virtual machines. This sends a stop command to
> > all bhyve(8) instances, regardless of whether they were starting
> > using vm or not.
>
> 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}
> }
>
> I wonder what the effect of the second kill is,
> that seems odd.
Indeed.
> Almost like you might cause more
> issues than you solve as now you already have a
> vm in what should be ACPI shutdown process.
>
> Also this killall operation probably puts a high stress
> on disk i/o as you just woke up and made all the vm's
> get busy all at once and your going to basically thrash
> on every single resource they are using (yet another reason
> you may actually want to serialize these shutdown operations.)
You are right.
>
> IIRC windows, especially newer ones, do a boat load of work
> on a shutdown unless they are told to shutdown quickly. Ie
> they even try to apply pending updates and such, that could
> be part of why you see windows vm's lagging around.
Do you know how to configure Windows for an unconditional ACPI shutdown?
Last time I stopped my Windows guests, they stopped pretty quickly. But
sometimes it just takes them forever to stop. Maybe it was giving a
shutdown warning to the users or something. Or maybe it was this issue:
https://serverfault.com/questions/871792/acpi-shutdown-does-not-always-work-on-a-windows-server-virtual-machine
> You may also want to: Disable Clear page file on shutdown
> that is a windows thing, if you have a huge page file that
> can do a LOT of io, if you have a few windows vm's on the
> same spindle and try to stop them all at once your going to
> trash that disk for much longer than you need.
Last time I checked on the Windows 2012 and 2016 servers, the
ClearPageFileAtShutdown setting was 0x0. I think it is the default.
> > > It may be possile to adjust vm_delay to 0 and have that be better,
> > > though I have not locked at the code. You may also wish to discuss
> > > the issue with the vm-bhyve maintainer and maybe a "lights out"
> > > procedure needs to be added.
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.
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
iQEcBAEBAgAGBQJcvnu1AAoJEA2k8lmbXsY0FG4IALkbCgpJ6ugOiqLaf6RCda/O
ja9YqiKfikCc4fGfa3YrxWSNoDzj/etoGOa/oagZ2xD3lcXBZSNYqm1xuxNWopgr
fSILZCN8UsJdZthe4id1n8HSbyLdiimiXEV9XmA+pUjxgJBlFMZOpZYDMoUioucU
AUSmX/4wG2jGjxzIvWTQPZy9YU/x/XxaRq89otsKKEFN2Cq+fH5itI0/40nTo79E
SRqqVUKQHdKl9i4AVRdUKyM631qynwon1W2jyn+w/GW6yvD//B+T02X71ArSVYVV
xKsiuhwUeca/pb1BH9lpVD+Auw712WaAta++dH5VqKGxHnRhmkR/bxS4PXzpWfU=
=Kz92
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190423024301.GA940>