I bet many of you that are virtualizing Citrix XenApp, have read the Project VRC whitepapers and want to implement their best practices. Especially in small environments however, it can be a headache creating the design. My biggest headache was and is, is the way I can guarantee no CPU over commit for the pCPU’s XenApp is running on.
Chapter 6.2 “vCPU overcommit & dedicated hardware” reads:
“Another important best practice, which is valid for all tested hypervisors, is not to overcommit the total amount of vCPU’s in relationship to the available logical processors on the system. For example, on a system with eight logical processors, no more than eight vCPU’s should be assigned in total to all VM’s running on this host.
This is only important when the primary goals to maximize user density. Various tests in phase 1 of Project VRC have proven that overcommitting vCPU’s negatively affects performance. This is not completely surprising since multiple VM’s now have to share individual logical processors, which will create additional overhead.
As a result, it is also recommended to use dedicated server hardware for Terminal Server and XenApp workloads, so it is easier to control VM configuration and assign vCPU’s in relationship to the available processors.”
Implementing this in a large scale environment shouldn’t be too difficult, you take a separate cluster, label it “XenApp” and add some hosts. In a smaller environment you might not have these dedicated resources. How to prevent that CPU over-commit when mixing XenApp and normal VMs? I have to take HA spare capacity in the equation and for the other VMs I probably want DRS enabled.
Resource pools? Hmm, not really. The shares defined in a resource pool only kick in when there is CPU contention, but they won’t prevent multiple VMs running on the same logical CPU. The limit you can enforce in a resource pool neither will save one core for a VM. If I would let DRS move VMs over multiple hosts, I can’t keep the XenApp VMs bound to one host. Excluding the XenApp VMs for DRS, won’t prevent other VMs moving to the same hosts. Unless you’re going to create anti-affinity rules, but that would make so many rules, DRS won’t be happy about it and managing them is a pain too.
Setting CPU affinity? That has never been anybody’s best practice I hope.
So, what are your ideas on this? Let me know in the comment section.