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

Victor Sudakov vas at mpeks.tomsk.su
Tue Apr 23 02:43:04 UTC 2019


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 at fidonet http://vas.tomsk.ru/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-virtualization/attachments/20190423/c43696d6/attachment.sig>


More information about the freebsd-virtualization mailing list