Skip site navigation (1)Skip section navigation (2)
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

--h31gzZEtNLTqOjlF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
> >=20
> > Whence is the idea that "vm stopall" does a sequential shutdown? What s=
ense
> > would that make?=20
>=20
> 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.
>=20
> 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.

>=20
> > A sequential startup does make sense but a sequential shutdown? Useless
> > I think. The man page says that=20
>=20
> For you perhaps useless, but that rarely rules out that there may be
> a totally valid and usefull case.
>=20
> >     stopall
> >              Stop all running virtual machines.  This sends a stop comm=
and to
> >              all bhyve(8) instances, regardless of whether they were st=
arting
> >              using vm or not.
>=20
> And the implementation is pretty brutal:
> # 'vm stopall'
> # stop all bhyve instances
> # note this will also stop instances not started by vm-bhyve
> #=20
> core::stopall(){
>     local _pids=3D$(pgrep -f 'bhyve:')
>=20
>     echo "Shutting down all bhyve virtual machines"
>     killall bhyve
>     sleep 1
>     killall bhyve
>     wait_for_pids ${_pids}
> }
>=20
> 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.
>=20
> 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.

>=20
> 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.

--=20
Victor Sudakov,  VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet http://vas.tomsk.ru/

--h31gzZEtNLTqOjlF
Content-Type: application/pgp-signature; name="signature.asc"

-----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-----

--h31gzZEtNLTqOjlF--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20190423024301.GA940>