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