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

[Itamar Heim]

On 11/15/2013 12:45 PM, Gianluca Cecchi wrote:
> 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
>

This *is* what the feature is doing.
define a pool of 500 VMs.
specify you want 10 autostarted VMs.
engine will make sure there are allways 10 launched VMs for users to 
get. and will launch new ones as needed (up to 10).

if 50 users will all ask for VMs at the same time, they will have to 
start them / wait the sysprep.
but if that's common - set auto start to 50.

oh - right terminology is "prestart VMs"