Date: Sun, 21 Apr 2019 10:08:13 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: Victor Sudakov <vas@mpeks.tomsk.su> Cc: freebsd-virtualization@freebsd.org Subject: Re: [vm-bhyve] Windows 2012 and 2016 servers guests would not stop Message-ID: <201904211708.x3LH8DiK028282@gndrsh.dnsmgr.net> In-Reply-To: <20190421154616.GA59283@admin.sibptus.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
-- Start of PGP signed section.
> Rodney W. Grimes wrote:
> > -- Start of PGP signed section.
> > > Jason Tubnor wrote:
> > > > On Sun., 21 Apr. 2019, 2:51 pm Victor Sudakov, <vas@mpeks.tomsk.su> wrote:
> > > >
> > > > >
> > > > >
> > > > > Does vm-bhyve provide a way to power them off ungracefully if they would
> > > > > not stop within a predefined time?
> > > > >
> > > >
> > > > You'd have to do your own checking but to force an instant power off of a
> > > > guest simply execute:
> > > >
> > > > vm poweroff {guest}
> > >
> > > I don't need an *instant* poweroff, I need a poweroff only if a VM would
> > > not stop gracefully within a predefined time.
> > >
> > > Of course this should not be done manually but from the rc.d/vm script
> > > on shutdown.
> >
> > vm shutdown {guest} &
> > (sleep N && vm poweroff {guest}) &
> >
> > A bit hackish, but that should work, if the guest has
> > shutdown by the time you get to the poweroff an error
> > might occur. This spawns a few processes, but is
> > non blocking and highly parallel.
>
> Thank you, I might give it a try though it would involve hacking the
> rc.d/vm script.
>
> >
> > One thing I noted, you said rc.d/vm, so I am assuming your actually
> > using the vm-bhyve port,
>
> Yes, I thought that was pretty obvious from the Subject line.
Subject line disappears off the screen once a screen full of
email gets displayed :-)
> > in which case it has a sequential shutdown
> > with time delays between each guest. vm_delay specifically, and it
> > shuts vm's down in reverse order of the startup.
> >
> > 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.
> 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. 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.)
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.
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.
> >
> > 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.
>
> Even if there is a single Windows 2012 or 2016 guest running, it takes
> the vm several minutes to transition to the "stopped" state.
You might nuke the wait_for_pids?
> Victor Sudakov, VAS4-RIPE, VAS47-RIPN
--
Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201904211708.x3LH8DiK028282>