multi core vcpu settings and confusion RDS / Terminal Services

[scale21]

I have a few terminal servers.

I run office apps, ie and a few other small things currently.

The VMs were setup with 2 vCpus from the start (i would have started with 1 however it wasn't me that set this up originally).

Its my understanding that once you go 2.....you cant go back to one because the hal for the VM is changed to SMP status or whatever and is non reversible.

Anyway.....my 2008r2 terminal servers hit about 25 - 30 users and start to choke out showing high cpu. Sometimes they get stuck at 100% for a bit if a single user is doing something intense.

I ran accross an article that talks about changing your cpuid.coresPerSocket.

(http://pubs.vmware.com/vsphere-4-esx-vcenter/index.jsp?topic=/com.vmware.vsphere.vmadmin.doc_41/vsp_vm_guide/configuring_virtual_machines/t_configure_multicore_cpus.html)

My hosts are dual quad core xeon procs.

If i add in and change my cpuid.coresPerSocket to be 1 will i get any benefit from this?

The way i read it is the vCPUs is the number of cores and the cpuid.coresPerSocket is just what it says.

being that i have 2vCPUs currently....if i designate 1 core per socket will i gain anything or is that essentially what i have now without adding this entry?

Other options to increase performance:

I dont really want to up my vcpus any more to try and increase performance as im sure that will just steal more resources/cpu time from the hosts (not to mention bad practice).

Im trying to squeeze a bit more performance out of the terminal server VMs that i have currently.

I dont really want to continue to build additional terminal servers. Ive got 12+ now and management is more and more messy every time i add them, although if that is my only option i can certainly do that.

[a_p_]

Whether it makes sense to add more vCPUs to the VM depends on the load of the VM itself and the load of the host. However, you could try to increase the vCPU count and revert to 2 vCPUs if things don't improve!?

Some comments on the other questions:

Its my understanding that once you go 2.....you cant go back to one because the hal for the VM is changed to SMP status or whatever and is non reversible.

This was an issue with Windows Server 2003 and earlier. Windows 2008 uses the same HAL for Uniprocessor and Multiprocessor systems.

The way i read it is the vCPUs is the number of cores and the cpuid.coresPerSocket is just what it says.

The vCPUs you set in the GUI is basically the total number of virtual cores. cpuid.coresPerSocket divides the number of configured vCPUs, resulting in virtual Multi-Core vCPUs. With e.g. 8 vCPUs configured in the GUI and cpuid.coresPerSocket set to 4, the host will present 2 Quad-Core vCPUs to the guest.

André

[scale21]

Thanks Andre. This helps confirm what i was thinking.

I could swear that once you went to 2 vcpu you could not get gains (if there are gains to be had) by going back to 1 vcpu.....hence always start with 1 and stick with 1 if at all possible.

I thought it was a vmware thing that was the limit...not necessarily a guest os thing, although i can see where a older guest os would come into play. I remember our instructor from my vcp class stating something like this as well although i cant find anything to back up the claim.

Anyway

In my situation now i have 2 vCPUs assigned. IF i add in cpuid.coresPerSocket and set it to 1, that would guaranty that im using 1 core from each of my 2 physical processors vs 2 cores from a single processor. I am not sure if there is any advantage to that or not.

[a_p_]

Afaik the cpuid.coresPerSocket setting does not have anything to do with physical core usage, but only divides the assigned vCPUs and therefore just defines how the vCPUs are presented to the guest OS. Setting it to 1 has the same effect as not setting it at all. Btw, specifying dedicated physical cores (CPU Affinities) is something that should be used with care as it limits the CPU scheduler and could lead to less overall performance.

Regarding the CPU usage of your terminal servers. I deployed hundreds of virtual XenApp servers, and it really depends on the applications used, the number of users on each server and the hardware what works best. Although in most cases the limitation was memory, I had situations where 2 vCPUs were not sufficient and I saw a much better performance by assigning 4 vCPUs.

André