[Users] avoiding sysprep per boot with pooled vms (was from irc)

[Gianluca Cecchi]

On Fri, Nov 15, 2013 at 6:32 PM, Bob Doolittle wrote:

>
> OK so there seems to be a serious scalability issue here. It is not unusual
> for a large VDI deployment to utilize hundreds of VMs. From what you're
> telling me, if we don't want users to experience the unsealing delay (which
> takes several minutes) every time, an admin would have to start all of those
> VMs after creating the Pool, and then cleanly shut them all down again once
> they'd all finished their unsealing process. Either that, or set them all to
> auto-start, but this puts unnecessary load on the host since they have to
> unseal after snapshot-revert every time they come up.
>
> There is perhaps an attractive feature that might help here. At the moment
> you can set an absolute number of "auto-start" VMs for the pool. I think
> what's needed is something more like an HA "standby" model which is applied
> to hosts and disks - you would like a certain number of not-yet-allocated,
> auto-started ("waiting-auto-started"?) VMs to be in the pool at all times
> (unless of course the pool is exhausted). In other words, say you have a
> large pool of VMs, and you set a waiting-auto-started count to 10. If 20
> users connect to VMs, 10 more would be started up and waiting in the pool.
> You could shut down/return any extras as VMs are returned to the pool
> (optionally?). The goal here is to eat the startup delays in advance to have
> ready-to-use VMs available for users at all times, without needing to start
> them all (which would consume excessive host resources). I think this would
> be more valuable than a fixed count, although maybe that's helpful in some
> use cases.
>

For sure it is interesting and mapping what there is in VMware since
long time where you can specify a limit of free started VMs after
which you autostart new ones at pool definition stage.

I put similar question at RHEV 2.x time for a POC I had in place when
the engine was Windows based and there was the command line API shell.
I was suggested and I verified it worked as expected with an at job
that every X minutes checked number of running VMs and when free
pre-started number dropped down a pre-defined limit it would pre-start
Y new VMs
I think now it should be also easier, even if it could be a good
proposal for 3.4

Gianluca