When virtualising general server workloads it is common, and desirable, to overcommit host resources to achieve a high consolidation ratio. General server workloads do not have interactive sessions, unlike a XenApp server. The end user is unlikely to notice spikes in utilisation on a virtualised file server or print server, however they are likely to notice even short spikes in utilisation on a virtualised XenApp server. The VM configuration has been carefully planned to ensure that host resources are not overcommitted which ensures host resources are available to XenApp VMs even when the host is under load.
Rule #1: Do not overcommit CPU
Total vCPUs <= Total logical CPU cores
Total vCPUs: The total number of vCPUs across all VMs on a host
Total logical CPU cores: The total number of physical CPU cores on a host, multiplied by two if hyperthreading is enabled (which is should be)
For example, take a host with dual hex core CPUs with hyperthreading enabled.
Physical CPU cores: 2 x 6 = 12
Logical CPU cores: 12 x 2 = 24
So with this host no more that 24 vCPUs should be assigned to XenApp VMs.
But what about the number of vCPUs per XenApp VM? There is no definitive rule here, only load testing with your specific configuration and workload will determine the optimal number of vCPUs per VM. The number of vCPUs must also be balanced with the amount of memory assigned to the VM. In general 2 - 8 vCPUs will be assigned to a XenApp VM.
If you found this useful keep an eye our for Rule #2 which will look at NUMA node considerations when virtualizing XenApp workloads.