I call this in /etc/rc.shutdown.local to shut all VMs down gracefully and
wait, perhaps a variant would help you.
#!/bin/sh
INTERVAL=5
/usr/bin/killall -TERM bhyve
echo -n "/dev/vmm:"
while test -d /dev/vmm ; do
echo -n "" $(/bin/ls /dev/vmm | /usr/bin/wc -w)
/bin/sleep $INTERVAL
done
echo " 0"
Stephen
On Tue, Apr 23, 2019 at 11:53 PM Victor Sudakov <v...@mpeks.tomsk.su> wrote:
> Rodney W. Grimes wrote:
> > > >
> > > > I've noticed that it takes too long for Windows 2012 and 2016 servers
> > > > guests to shutdown when I issue "vm stopall," several minutes even.
> > > >
> > > > Does vm-bhyve provide a way to power them off ungracefully if they
> would
> > > > not stop within a predefined time?
> > > >
> > > > Or is there perhaps a way to tune the guest OSes to react more
> promptly
> > > > to an ACPI shutdown?
> > > >
> > > > My primary concern is that my UPS and "apcupsd --kill-on-powerfail"
> give
> > > > me about 30 seconds of grace time before the power supply is cut
> out. It
> > > > is not sufficient for the bhyve box to shutdown shutdown properly
> > > > because it waits for the guests to shutdown.
> > >
> > > For the present I think I've found a workaround not directly related to
> > > vm-bhyve. I'm going to insert "service vm stop" into the doshutdown()
> > > procedure in /usr/local/etc/apcupsd/apccontrol before the actual
> > > ${SHUTDOWN}. It should give the VMs sufficient time to shutdown before
> > > the actual /sbin/shutdown is executed.
> >
> > Make sure it does not do the waitall for pids or your going to
> > sit here waiting for that to complete for a long time, ie until
> > all vm's go to power off.
>
> In fact, this is my intention to sit here waiting for all VM's to go power
> off.
>
> I can configure apcupsd to start the doshutdown() routine when there is
> enough power in the UPS, like maybe for 20-30 minutes.
>
> > > > If you know of a better way to configure apcupsd so that it powers
> down
> > > > the UPS only after all the guest OSes and other daemons are safely
> down,
> > > > I'd appreciate that too.
> > >
> > > Do you think the above hack would have any negative effects?
> >
> > I think this is a reasonable approach given the current situation.
> >
>
> --
> Victor Sudakov, VAS4-RIPE, VAS47-RIPN
> 2:5005/49@fidonet http://vas.tomsk.ru/
>
_______________________________________________
freebsd-virtualization@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
To unsubscribe, send any mail to
"freebsd-virtualization-unsubscr...@freebsd.org"
