Stephen Stuart wrote:
> 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 |
Victor Sudakov wrote:
>
> 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
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
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
> Victor Sudakov 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?
>
Victor Sudakov 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
> On Apr 22, 2019, at 21:13, Victor Sudakov wrote:
>
> Paul Vixie wrote:
>>
>> Victor Sudakov wrote on 2019-04-22 19:43:
>> ...
And the implementation is pretty brutal:
# 'vm stopall'
# stop all bhyve instances
# note this will also stop instances not started by vm-bhyve
Victor Sudakov wrote on 2019-04-22 21:13:
...
sleep 1
...
i think this is worse than brutal, it's wrong. consider freebsd's own
work flow when trying to comply with the first soft shutdown it got:
https://github.com/freebsd/freebsd/blob/master/sbin/reboot/reboot.c#L220
this has
Victor Sudakov wrote on 2019-04-22 19:43:
...
>> 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
-- Start of PGP signed section.
> Paul Vixie wrote:
> >
> > Victor Sudakov wrote on 2019-04-22 19:43:
> > ...
> > >> And the implementation is pretty brutal:
> > >> # 'vm stopall'
> > >> # stop all bhyve instances
> > >> # note this will also stop instances not started by vm-bhyve
> > >> #
> > >>
> Victor Sudakov wrote on 2019-04-22 19:43:
> ...
> >> 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:')
> >>
> >>
Paul Vixie wrote:
>
> Victor Sudakov wrote on 2019-04-22 19:43:
> ...
> >> 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
Victor Sudakov wrote on 2019-04-22 19:43:
...
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
Victor Sudakov wrote:
[dd]
> > > > 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
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
> >
-- 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,
> > > > wrote:
> > > >
> > > > >
> > > > >
> > > > > Does vm-bhyve provide a way to power them off ungracefully if they
Rodney W. Grimes wrote:
> -- Start of PGP signed section.
> > Jason Tubnor wrote:
> > > On Sun., 21 Apr. 2019, 2:51 pm Victor Sudakov,
> > > wrote:
> > >
> > > >
> > > >
> > > > Does vm-bhyve provide a way to power them off ungracefully if they would
> > > > not stop within a predefined time?
>
-- Start of PGP signed section.
> Jason Tubnor wrote:
> > On Sun., 21 Apr. 2019, 2:51 pm Victor Sudakov, 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
Jason Tubnor wrote:
> On Sun., 21 Apr. 2019, 2:51 pm Victor Sudakov, 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
On Sun., 21 Apr. 2019, 2:51 pm Victor Sudakov, 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}
Dear Colleages,
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
21 matches
Mail list logo
