Have you started using XenDesktop 5 yet?
Here’s something to look out for, as I know many people have been wondering. Remember in XenDesktop 4, we could specify our available desktop count (idle pool)? First, we have a desktop group of 1,000 desktops. We might specify 800 desktops idle at 8:00AM, then at 11:00AM we drop down to 200 idle desktops, and so on. XenDesktop 5 does the same thing, but a little bit more. XenDesktop 5 will start 800 desktops at 8:00AM, just like XenDesktop 4, but that is where the similarities end. Here is what happens next:
XenDesktop 4 | XenDesktop 5 | |
1 user logs on | One new desktop starts to bring available desktop count back up to 800 | Available desktop count stands at 799 |
49 more users log on | 49 new desktops start to keep the available desktop count at 800 | Available desktop count stands at 750 |
650 more users log on | 650 new desktops try to start to keep the available desktop count at 800, but only 150 more are defined. Available desktop count drops to 400. Errors appear in event log. | Available desktop count stands at 100 |
1 more user logs on | 1 new desktop tries to start to keep the available desktop count at 800. No more desktops defined.Available desktop count drops to 299. Errors appear in event log | One new desktop starts to keep available desktop count at 100 |
100 more users log on | 100 new desktops try to start to keep the available desktop count at 800. No more desktops defined.Available desktop count drops to 199. Errors appear in event log | 100 new desktops start to keep available desktop count at 100 |
What just happened? Why doesn’t XenDesktop 5 keep 800 desktops idle? Because XenDesktop 5 is smarter than XenDesktop 4. Think about it. If I have about 800 users arriving at 9:00AM, I want to have these desktops ready to go before they arrive, so I set the available desktop setting at 800 starting at 8:00AM. Why do I need to keep 800 desktops idle when users start logging in? I only have 1000 total users. This seems rather pointless to me. It’s a waste of resources. Even if you don’t have additional desktops defined, you won’t have resource waste, but you will end up with a polluted event log on the controller. That is why XenDesktop 5 is smarter. XenDesktop 5 includes a pool buffer setting applied to each desktop group. XenDesktop 5 won’t start new desktops until the buffer threshold is breached. By default, this buffer is 10% of the size of the desktop group, but it is configurable via PowerShell.
If you do a “Get-BrokerDesktopGroup” in PowerShell, you will see OffPeakBufferSizePercent and PeakBufferSizePercent. Two buffers for two timeframes (Peak and Off-Peak).
How do you change it? With the “Set-BrokerDesktopGroup” setting.
Hopefully, this explains one of the production-level differences I’ve seen between XenDesktop 4 and 5.
Daniel – Lead Architect
XenDesktop Design Handbook
[…] This post was mentioned on Twitter by Daniel Feller, John Carey, ChaosNL, ChaosNL, Hank Smith and others. Hank Smith said: "@djfeller: This 1 has confused many #Citrix #XenDesktop 5 implementations… Power Management http://t.co/ZAdb81R > good stuff Dan […]
LikeLike
[…] What is XenDesktop 5 Power Management Doing […]
LikeLike
question – what are the peak/off peak extended settings?
LikeLike
Very good article! Thank you for explaining this. Very easy to understand the way you explained it 🙂
LikeLike
[…] The buffer is unallocated VDIs that are powered on when the number of machines in the pool drops below the buffer threshold. By default the buffer is 10%. The buffer stops XenDesktop trying to power on more machines than it actually has available within the pool. Daniel Feller explains Buffers in his blog post here […]
LikeLike