In Part 1 of this series I discussed the changes we made to control the load placed on the hypervisor by the XenDesktop pool management service. In Part 2 I described the changes we made to lock down certain roles within the XenDesktop farm to provide a more stable and predictable farm.
As always with these kinds of investigations after clearing the major changes out the way we were left with a number of changes that I group together as “other”. In the final part of this series I will describe some of the changes we made, as well as some advice that I gave to the customer to help them maintaining their XenDesktop farm in the longer term.
These items were:
• Reconfigure the Wyse terminals to download their config from a different server
• Install latest hotfixes for XenDesktop 3
• Update VDA to latest version 3.1.3255
• Plan for installation of Update 6 for VMware Virtual Centre
• Longer-term items: Keep up-to-date with hotfixes
• Upgrade to XenDesktop 4 to remain in support
• Separate DDC VMs from the virtual desktop VMs
Wyse Terminal Configuration
I have never had the chance to work with Wyse terminals so I cannot give a really detailed description of what was changed. However as we reviewed the customer’s infrastructure I was told that when the Wyse terminals boot they are configured to download their config from a server chosen by the administrator. In this environment the customer had chosen to download the config from the pool master server; adding a significant load on this very important infrastructure component.
The customer removed the load on the Pool Master by reconfiguring their Wyse terminals to download their config from one of the other DDCs in the farm.
Hotfixes for XenDesktop
The DDCs had not been kept up-to-date with hotfixes. I recommended to the customer that they install all available hotfixes. I had several reasons for doing this:
• The latest pool management hotfix contained specific fixes for memory consumption that the customer had observed in the environment
• If during our investigation the customer had found a bug we will always ask them to verify that the problem persists when running the latest version of the code
At the time we started this investigation the latest hotfixes for XenDesktop 3 were:
Latest VDA version
At the time the latest VDA version for XenDesktop 3 was 3.1.3255. The customer deployed this to all their virtual desktops to ensure, again, that they were running at the latest code level. For XenDesktop 4 customers we recommend that all VDAs are at least running version 4.0.5010 (also known as the Service Pack 1 VDA) which contains huge numbers of bug fixes and stability enhancements.
Update 6 for VMware Virtual Centre
The customer was running vCentre 2.5 Update 5 for their ESX management. I knew that Update 6 was available and recommended they deploy this update. Maintaining reliable communication between the pool management server and the vCentre server is extremely important for maintaining a stable XenDesktop environment, so ensuring that the code at both ends of that conversation is up-to-date is very important.
In the longer term I recommended that once the environment had been stabilised that the customer immediately start planning the upgrade to XenDesktop 4. XenDesktop 3 went end of life on December 31st 2010, while XenDesktop has another 2 years of support. Knowing that enterprise customers generally have a long lead-time for deploying new infrastructure, I suggested they start the XenDesktop 4 deployment as soon as possible so that they could continue to receive support.
Separation of DDC VMs from VDA VMs
In this environment the customer had their infrastructure servers virtualised in the same ESX cluster as the desktops. We recommend that infrastructure servers are hosted in a different cluster, on separate physical servers and ideally managed by a separate vCentre server. This then prevents a hardware problem, or heavy load on the VDAs from affecting the XenDesktop infrastructure. However in this environment the customer had limited rack space and hardware to change their design so dramatically, so we had to leave the environment as is.
I hope this series of articles has been interesting and useful. Over the next few weeks I will be documenting some other interesting cases that I have worked on while supporting our Enterprise customers.