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

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