Windows 2003 Terminal Server as a VMware Guest

Running Windows as a guest in VMware is way cool, since this breaks the evil bond Windows enters with your hardware, acting as if the GUI was the OS. A few things to observe when setting up a Windows 2003 Terminal Server with VMware Server.

Idea

With the release of VMware Server for free, it has become very simple to run virtual machines on a server. We use it to run Windows 2003 Terminal Servers on multi core boxes to provide Windows Applications to Linux Desktops and Thin Clients.

Setup

Observe the following rules when setting up your W2K3 VMware guest and you should be all set.

Disable serial and parallel ports in the VMware BIOS. You don't need them and they use up resources.
Preallocate Diskspace. Rather spend the time now, then while the system is up and running.
Disable snapshots. They are ultra-cool, but they eat up some of the performance
Enable disk caching on the disk image in case it was turned off.
In the .vmx file add the following:
```
MemTrimRate = "0"
sched.mem.pshare.enable = "FALSE"
sched.mem.maxmemctl=0
MemAllowAutoScaleDown = "FALSE" 
mem.ShareScanTotal=0
mem.ShareScanVM=0
mem.ShareScanThreshold=4096
```
These settings will stop vmware from trying to save memory on that virtual machine by moving it to disk and sharing it with other vmware instances. While this is very effective in reducing the memory footprint of your vmware guest, it can also cause it to be slow, especially when memory has to be pulled back up from disk. Obviously this will only work if you actually do have enough memory in your system. You can see if the settings work, if you look at the vmware-vmx process with top, and find that RES and SHR memory counters are in the vicinity of the VIRT counter.
Tell VMware (in the Host Menu) to hold all the Memory allocated to the VMware guest in real memory.
Assign a sufficient amount of memory to the VMware server instance, so that all the guest memory fits in.
One might think that this would make vmware keep all memory in ram but you will still find a vmem file sitting in the vmware directory. Vmware memory mapes this file and uses it as memory for the vmware-vmx instance. The advantage of this is, that if you suspen the virtual machine, this will be very quick and linux will take care of writing the memory back to disk. Unfortunately the writeback also happens during normal operation and can have rather unfortunate performance impacts. One might think that the following option helps:
```
mainMem.useNamedFile = "FALSE"
```
It does help indeed, as the vmem file is gone. But running lsof on the vmware-vmx process holds an open file handle to a deleted file in /var/tmp (or /tmp). This file has taken the place of the vmem file and eventhough it is deleted recent linux kernels will insist on syncing its content back to disk. The sollution to this problem is to make vmware put its memory file into a tmpfs filesystem a good candidate it /dev/shm, as long as you make sure it is large enough. Edit /etc/fstab to limit the size of /dev/shm to a bit more than the ram allocated to your vmware images.
```
none /dev/shm  tmpfs   size=8g  0    0
```
Remount the /dev/shm filesytem and edit /etc/vmware/config file to point to the tmpfs:
```
tmpDirectory = "/dev/shm"
```
Now you can restart the vmware instances and use lsof to verify that they are now keeping their mmap files in tmpfs. Note that this trick does NOT use the memory twice.

There is ongoing discussion about the performance impacts of assigning two CPUs to a W2k3 guest. For now we leave it at 1 CPU.

In the Windows section of the website there are some Notes on Windows 2k3 tuning for even better performance.

War Story

We recently spent a lot of time optimizing a customers W2K3 instance (this is where all this info comes from) only to eventually figure out, that the bad performace, was due to Windows XPe ThinClients that were writing directly to their flash drives. Once the RAM-Disk-Redirection driver on these Boxes was enabled, performance improved considerably.

Windows XPe ThinClients normally work on an internal flash drive. Flash is fine for reading but quite slow for writing. On some ThinClients there is a program built in which lets you redirect all write operations to RAM. Since ThinClients are not suposed to store anything on the local flash anyway this is a good way to make flash fast.

NOTE: The content of this website is accessible with any browser. The graphical design though relies completely on CSS2 styles. If you see this text, this means that your browser does not support CSS2. Consider upgrading to a standard conformant browser like Mozilla Firefox, Opera, Safari or Konqueror for example.