Hi,
On Wed, 28 Jun 2017 12:05:46 +0200
"Paul" <[email protected]> wrote:
> Hi Sharon,
>
> Thanks for your comments. My findings on those:
>
> 1. Yes all VMs have ovirt-guest-agent installed and active, shutdown
> time is still about 90 seconds. Any other way to reduce this? I see in the
> logs “Jun 28 11:49:03 pool python: Shutdown scheduled for Wed 2017-06-28
> 11:50:03 CEST, use 'shutdown -c' to cancel.” And then a wait of 60 seconds.
> Is it possible to adjust this delay?
I've got good news for you... and, of course, some not so good news...
The delay can be configured in engine by engine-config. The
corresponding value is 'VmGracefulShutdownTimeout' and is in seconds
(default is 30 seconds). I.e. you can run the following to disable the
delay.
# engine-config --set VmGracefulShutdownTimeout=0
The not so good news is that on linux (which is your case if I
understood correctly) the delay only works by minutes and the value of
VmGracefulShutdownTimeout is rounded *up* to whole minutes. That is
anything between 1-59 seconds is turned into 60 seconds.
Hope that helps,
Tomas
>
> 2. Clicking twice works. Thanks for the tip!
>
> 3.
>
> a. More VMs per user: yes, could be a good option
>
> b. I have some trouble with the “console disconnect action” and filed a
> bug for it last week [1]. Any disconnect action (except shutdown) combined
> with “strict user checking” (security wise recommended) blocks and depletes
> pool resources and in my opinion jeopardizes the pool functionality. I am
> curious what your thoughts are on this.
>
> Kind regards,
>
> Paul
>
> [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1464396
>
>
>
> From: Sharon Gratch [mailto:[email protected]]
> Sent: dinsdag 27 juni 2017 19:04
> To: Paul <[email protected]>
> Cc: users <[email protected]>
> Subject: Re: [ovirt-users] vm shutdown long delay is a problem for users of
> pools
>
>
>
> Hi,
>
> Please see comments below.
>
>
>
> On Thu, Jun 22, 2017 at 7:15 PM, Paul <[email protected] <mailto:[email protected]> >
> wrote:
>
> Hi,
>
> Shutting down VM’s in the portal with the red downfacing arrow takes quite
> some time (about 90 seconds). I read this is mainly due to a 60 second delay
> in the ovirt-guest-agent. I got used to right-click and use “power off”
> instead of “shutdown”, which is fine.
>
>
>
> My users make use of VM in a VM-pool. They get assigned a VM and after
> console disconnect the VM shuts down (default recommended behavior). My issue
> is that the users stays assigned to this VM for the full 90 seconds and
> cannot do “power off”. Suppose he disconnected by accident, he has to wait 90
> seconds until he is assigned to the pool again until he can connect to
> another VM.
>
>
>
> My questions are:
>
> - Is it possible to decrease the time delay of a VM shutdown? 90
> seconds is quite a lot, 10 seconds should be enough
>
>
>
> Is ovirt-guest-agent installed on all pool's VMs? Consider installing
> ovirt-guest-agent in all VMs in your Pool to decrease the time taken for the
> VM shutdown.
>
>
>
> - Is it possible for normal users to use “power off”?
>
> There is no option in UserPortal to power-off a VM but you can
>
> try to click twice (sequential clicks) on the 'shutdown' button. Two
> sequential shutdown requests are handled in oVirt as "power off".
>
> - Is it possible to “unallocate” the user from a VM if it is
> powering down? So he can allocate another VM
>
> You can consider assigning two VMs per each user, if possible of-course (via
> WebAdmin->edit Pool -> and set "Maximum number of VMs per user" field to "2")
> so that way while one VM is still shutting down, the user can switch and
> connect to a second VM without waiting.
>
> Another option is to create a pool with a different policy for console
> disconnecting so that the VM won't shutdown each time the user close the
> console (via WebAdmin->Pool->Console tab->"Console Disconnect Action").
> Consider changing this field to "Lock screen" or "Logout user" instead of
> "shutdown virtual machine".
> This policy will avoid accidentally console disconnection waiting each
> time...but on the other hand the VM state will remain as is since no shutdown
> occurs, so it really depends on your requirements.
>
> Regards,
>
> Sharon
>
>
>
> Kind regards,
>
>
>
> Paul
>
>
> _______________________________________________
> Users mailing list
> [email protected] <mailto:[email protected]>
> http://lists.ovirt.org/mailman/listinfo/users
>
>
>
--
Tomáš Golembiovský <[email protected]>
_______________________________________________
Users mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/users