Terminal server 2008 virtualization ?

[timdevries]

Good day.

I have been searching the internet on virtualization 2008 terminal server. I am now running several installations of 2008 terminal server on several ESX 3.5 installations.

My hardware boxes:

HP DL380 dual quad core 3GHz.

20 GB of ram

P400 controller with 512MB of cache

Local mirror of 300GB SAS

Most of my virtual servers running 2008 terminal server are having poor performance... When running with 20 logged on users the performance is really bad.

When running default applications like office

I tried different settings on my virtual machines 1 vCPU and dual vCPU with reservation. All my 32bit installations have 4GB reserved RAM.

Anybody have a good idea of tweaks for better performance ?

It looks like 2003 R2 terminal servers have a lot better performance.

[RParker]

Despite what you read or hear, Windows 2008 is more resource hungry than Windows 2003. So I would bump up the memory from what you are used to in Windows 2003.

How much resource are you giving Windows 2008 for Terminal Service? I think Microsoft is going backwards rather than forwards....

[timdevries]

my 32-bit virtual 2008 terminal servers are having 2 vCPU's 3Ghz dedicated.

4 GB of RAM reserved

2 Vdisks and a seperate disk for the swapfile.

My 2003 Terminal servers are configured with te exact same configuration.

[RParker]

My 2003 Terminal servers are configured with te exact same configuration.

Well we have machines half that in every respect that perform pretty well (although we don't have any multi user 2008 machines) and they don't have issues. Users complain but then what else is new. They don't see the big picture, and for the time they are using it, everyone on a team uses it for 4 hours, and they want to me to give them more resource for 4 hours out of the day, and the machines sit for the other 20 hours.. not a whole of of business need there, and I monitor the machines. Memory is fine, disk is fine, it's their programs that hog the machine, and each one of them have identical processes all at the same time.

So I tell them...it would appear you are all doing the same things at the same time, I think you need to communicate more effectively with your team, because you are duplicating your efforts. Since they spike the machine for very short periods of the day, relatively speaking, I don't see any reason to give them what they want, since they aren't technical. It wouldn't make a difference anyway.

So the bottom line is, I try to ensure that all the resources are there, they have everything they need and to them 'slow' is in comparison to their physical laptop.. And I have to run through the usual, well you don't have 9 other users connecting, you have a physical machine, and let's not forget when you are using remote desktop you AREN'T using your local machine at that moment are you...

Of course they can't say anything after that

[JoJoGabor]

I am always extra careful when it comes to virtualising TS boxes. I stick to the following recommendations:

Use 2vCPU per VM

Run no more than 1 vCPU per pCPU, or 1.5 as an absolute maximum

Create 3 VMDK, One for System, one for a pagefile (2x RAM) on the fastest disk possible, and one for applications

ENsure all partitions are aligned to 64KB blocks

Use 64-bit Windows and give it plenty of RAM

Do not overcommit memory, in fact disable memory sharing on the VMs

If you still get issues then its time to resort to splitting applications between different TS servers and split those between hosts (not nice)

[RParker]

Run no more than 1 vCPU per pCPU, or 1.5 as an absolute maximum

That contradicts consolidation ratios. You can do 8 vCPU per pCPU now.. so that 'maximum' would severely limit you. It depends on what your TS is doing.

Create 3 VMDK, One for System, one for a pagefile (2x RAM) on the fastest disk possible, and one for applications

There are numerous white papers that also dispel theory that 'more virtual disks' will give you more speed, or alleviate bandwidth issues, in fact it's more overhead for the VM to handle additional I/O you actually get better speed by running a single VMDK per VM. They still use the same underlying RAID controller and connection to your SAN, so you are competing with the IO within the same VM.

The rest is quite true, 64-bit VM's (if only for TS purpose), lots of RAM (usually 128 meg per user above 1G base -can't remember numbers exactly), but sharing the memory isn't a problem if as you say don't over commit.

[JoJoGabor]

VIrtualising Terminal Services boxes in my opinion is the hardest type of virtualisation to do successfully. It appears to be to be a black-art, you can look at performance metrics such as RAM and CPU used and it all looks OK, yet user performance is dire.

The number of vCPU per pCPU is wholly dependant on the workload of the servers. WHen it comes to virtual TS boxes, performance is often degraded very severely, and their are whitepapers on the VMware website about doing this (specifically with CItrix) which make these guidelines. It is something to do with context switching and an outer-ring in the processor (this goes over my head), but you can't expect to get consolidation ratios as high as other low-utilised servers.

You may be right about raw performance by having a single VMDK, but I have tested splitting out the pagefile and apps and it improved performance - I cant explain why. I got this reommendation from this blog...

[TomHowarth]

Also remember that just because it is virtual it is still costed. inform your users that they can have what they want if they present a PO for (insert cost of extra VM host, ESX license, MS licesnse etc)

If you found this or any other answer useful please consider the use of the Helpful or correct buttons to award points

Tom Howarth VCP / vExpert

VMware Communities User Moderator

Blog: www.planetvm.net

contributing author for the upcoming book "VMware Virtual Infrastructure Security: Securing ESX and the Virtual Environment”.

[msemon1]

It also depends if you are giving users published desktops or applications and what kind of applications that run on Windows Terminal Server /Citrix. If they are cpu or memory intensive in the physical world then you will have the same problem in the virtual world. Context switches were a problem with ESX 2.5, however, I have not noticed that with 3.5.

Mike