[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