The User overflow and how to solve it with a Backup Global entitlement in VMware Horizon.
With al little creativity and bending we also see this in a VDI environment, I name this a User Overflow:
[a] condition at an environment under which more users try to be placed into a pool than the capacity allocated,
Of course with VMware Horizon you can make the pools dynamic in size but you will be limited by the available hardware resources. Yes, you can overprovision but wat if the resources have a hard limit, like when using hardware accelerated vGPU’s like Nvidia Grid?
What if you need to temporary facilitate these users anyway? Let’s create an overflow pool with the help of a backup global entitlement!
We’ve al been there… to many users to handle! And yes.. some users look and behave like zombies..
On a normal day every user can login and is very happy with the awesome environment you build.
Suddenly multiple hardware failures or there is an unexpected rise in users (maybe the customer found multiple busses loaded with new employees even in this market). Replacement or additional hardware is ordered but not quickly available and dynamically expanding in to the cloud is not an option sometimes. Or maybe, the limit of the pool is rarely but unexpectly hit?
At a customer we ran into this problem. In the original design a vGPU was a requirement for every VDI session. The environment was designed relatively tight by constraints and when the request came for additional VDI’s luckily there was enough memory and CPU available but no more GPU’s to slice. The environment max limit was hit but on a rare occasion. Additional hardware is ordered but due to the shortage in hardware everywhere shipment is (very… very… ) delayed.
The result, there are users who can’t login..and there he is.. an angry user:
Okay but these users really need to work so we agreed a session without vGPU is better than no session at all. The first strain of thought was to just create a local pool with no vGPU and assign this pool to the Global pool assignment or alternatively only assign the new users to the new pool. But this would result in VDI’s with no vGPU’s being handed out when there are desktops with vGPU available. No, we agreed, the VDI’s with no vGPU must only be used when the pool with vGPU runs out of capacity.
How to achieve this?
Environment build and designed as Cloud POD Architecture so users connect to a Global Entitlement instead of a local pool directly.
Enough resources to facilitate this additional VDI’s.
Only available for floating assignments
At first create an additional local pool. When using instant clones I would suggest to deploy them on demand with a minimum standing by. Provisioning is really fast and I think a waste to let those IC’s consume resources when they are only here when really needed in rare circumstances) In below example there are a minimum of 10 machines with 5 machines always ready for a new session with a max of 200 IC’s.
Size this to your requirements and possible limits.
Don’t entitle any users to this pool, as you normally won’t do on a local pool when using Global Entitlements.
The Global Entitlement
Create a new Global Entitlement, give it a logical name. Don’t worry about the display name the users won’t see this
Next, don’t assign any users or groups to this new Global Entitlement
And Finish the wizard and there is the additional Global Entitlement with no user or groups entitled!
Click the new Global Entitlement that you just created and add the local pool created earlier.
So… now we have a "Global Pool Overflow" with a local pool attached and no users.. now what?
Edit the Global Pool you want to assign the Overflow pool as backup to. Look for “Backup Global Entitlement” and click the Browse button next to it.
Select the backup Global Entitlement you created
And there it is! click submit to save this configuration
What will happen now?
Well when the Global pool is full or unavailable the user will be redirected to the backup pool assignment.
Since we created this pool with IC’s on demand this pool will expand when necessary. There is no action required on the user part and the user can still login as they are accustomed to but of course.. in the scenario stated earlier they will not have a hardware accelerated GPU when getting a session in the overflow pool.
When the environment cools down and the user will start a new session they will have vGPU again.
Don’t forget to keep the assigned master image in sync 😉 You can use the same image for both pool's.
So we have a relatively happy zomb.. euh user in case of resource constraints or failures!
And in my humble opinion this could be a fair strategy for maintenance .
Any comments, questions or remarks? please let me know!