Thats some cool data; one interesting thing is the increase in context switches, I wonder if the more you load those VMs that your unacceptable percieved performance would come not from memory or simple cpu time but from a sort of application wait state due to to many context switches. Which if the case would bring up another question if you where to dedicate a host to run only citrix vms what would the ideal host cpu characteristics be like.
We know as Citrix administrators there exists a user count threshold where performance and user experience tanks. We haven't hit that yet with 40 users on our Citrix VMs. I've asked for my manager's approval to take one of the Citrix servers out of the silo which will force user count per server to ~50 so we can start to discover where exactly that threshold is in a Citrix VM with our application silo specific characteristics. The threshold will change from silo to silo. For this particular application silo, the threshold may be 50 users. For a silo that runs other applications, that threshold may be much lower, like 20 users. It all depends on the published application load in the silo.
Trust me, I'm keeping a keen eye on context switching. It's already reaching the boundaries of my comfortability level but if end user performance is not suffering, I can raise my context switching alarm level from 18,000/sec. to say 30,000/sec. Again, it's all about finding the sweet spot just before the tanking starts to happen.
I would be under the impression that the threshold on the citrix server would be a controlled by the processors ability to complete transactions and switch to the next request, maybe processor Queue would be a good place to monitor.
My citrix servers are running on average of 25 users each and get very good application response these are free floating along with all the other VMs, ill post some stats next week; and the modifications I made maybe you have some more tricks I can add to my boxes.
I would definitely like to see what you are doing. From my side, I don't have any tricks up my sleeve as far as the VM configuration or the guest configuration. One of the benefits ESX 3.x brought to us was they eliminated the need to specify the "workload = terminalservices" parameter in the .vmx file which one needed to use on ESX 2.x for tuning. It's automagic in ESX 3.x. As far as customizations inside the guest OS after the P2V, that list isn't too lengthy because I don't want my Citrix platforms to be radically different between physical and virtual for support reasons:
P2V Steps
VMware VirtualCenter/ESX:
1. Create a new VM from scratch
a. Microsoft Windows Server 2003 Standard Edition
b. 1 vCPU
c. 4,096MB RAM (4GB RAM)
d. 1x 37GB LSI Logic SCSI drive
e. 1 NIC, tied to appropriate network
f. Detach any attached floppy and/or CD-ROM devices
g. Set floppy and CD-ROM devices to host based
Using P2V Assistant (Compresses down to 3.5GB tar.gz):
1. Boot physical server using P2V Assistant boot CD
2. If using Fast Ethernet on the physical server or switch, follow these sub steps on the physical server once it is finished booting up from the CD:
a. Close the P2V Server application window
b. hard code NIC speed/duplex to 100Mbps/Full Duplex:
i. Open a terminal session console
ii. Switch user to root by issuing the command: su –
iii. Issue the command: mii-tool –F 100baseTx-FD eth0 (and/or eth1 depending on how many NICs are detected)
iv. Issue the mii-tool command once again to verify NIC(s) are at the correct speed/duplex
v. Close terminal console
vi. Re-launch P2V Server application window for which there is an icon on the desktop
3. Add a 37GB virtual SCSI disk to the helper VM. This will be an existing drive which would have been created when the new VM was created from scratch early on
4. In Windows Disk Management, “rescan” the disks so that the new disk can be seen.
5. Install P2V Assistant software in helper VM
6. Launch P2V Assistant application
7. Select a task: “Clone a source…”
8. Enter the IP address of the server which was booted with the P2V Assistant boot CD. The IP address will be on display on the physical server in the P2V Server application window.
9. Highlight the drive and choose next
10. Choose “Yes, clone the disk, then reconfigure system files in the target disk”. If you do not choose this option, the VM will not boot due to inaccessible boot device BSOD.
11. Uncheck both of the following two boxes:
a. Uncheck Do not copy temporary system files such as pagefile.sys and hyberfile.sys
b. Uncheck Do not copy temporary internet files
12. Choose “Use a direct disk device…”
13. Click the “Select” button and choose the new disk from step 3.
14. Target VMware Product, choose “ESX Server 2.1.x, 2.5.x, or 3.x (1vCPU).
15. Of the remaining two boxes:
a. Uncheck the box for pre-installing the temporary SVGA driver
b. Check the box for Attempt to preserve drive letter to volume mappings (by default it is already checked)
16. The P2V process will complete after a period of time. Usually around 20-60 minutes depending on hardware and network speeds.
17. At the end, VMware may warn you of an error in the P2V process regarding a long file name issue. This appears to be OK to ignore.
18. Shut down the helper VM and power off
19. Detach (remove) the 37GB virtual SCSI disk from the helper VM. DO NOT delete the disk from the datastore!
20. We need to disable all HP services in the P2V’d VM. Failure to do this will cause one of the HP Insight 7.90 services to hang the VM at the logon screen and use 100% of the ESX host processor:
a. Reboot the P2V’d VM into Winternals ERD Commander 2005
b. Select the Windows installation you wish to repair: D:\WINDOWS Microsoft Windows Server 2003 R2 Server, Service Pack 1
c. Open the Service and Driver Manager
d. Disable all HP services. Failure to do this will cause one of the HP Insight 7.90 services to hang the VM at the logon screen and use 100% of the ESX host processor
e. Choose Start|Log Off|Restart
f. After the helper VM reboots and goes through POST, power it off. Don’t let it boot into Windows.
Using VMware Converter (Compresses down to 13GB tar.gz):
1. VMware Converter could be used as an alternative to the P2V Assistant tool in order to migrate the physical server into a VI3 virtual infrastructure, however, it will create less compressible .vmdk file which considerably lessens the .vmdk’s portability because it won’t fit on a DVD when using this tool
2. For maximum efficiency, configure the correct NIC speed/duplex before starting the P2V process
3. Before powering on the new VM for the first time:
a. Change virtual SCSI controller type from BusLogic to LSI Logic (not performing this step will result in BSOD when booting to the Command Console or finding no hard drive when booting to ERD Commander 2005)
b. Set virtual RAM to 1,024MB
c. Set number of processors to 1
d. Remove any virtual USB or Serial port virtual hardware
e. Detach any attached floppy and/or CD-ROM devices
f. Set floppy and CD-ROM devices to host based
4. There are other steps and considerations to complete this parallel process properly and consistently with the P2V Assistant process to arrive at the same end point but in the interest of time conservation, I’m not going to go through it all here. The fact that VMware Converter generates a .vmdk file that won’t compress down to a reasonable size does not make this alternative attractive at all.
Boot to Windows 2003 OS:
1. Before powering on the new P2V’d VM:
a. Remove any virtual USB or Serial port virtual hardware
b. Detach any attached floppy and/or CD-ROM devices
c. Set floppy and CD-ROM devices to host based
2. Power on the new P2V’d VM and boot into Windows
3. Windows Server 2003 will find a bunch of hardware. When it asks you to reboot, don’t
4. Install VMware Tools (Complete installation)
5. When asked if you’d like to set hardware acceleration, choose Yes. This will bring up the display properties sheet. Click the Advanced button. Troubleshoot tab. Move the slider from None to Full and then click OK. Change resolution to 1024x768. Click OK.
6. In Device Manager, remove both COM ports and Parallel port
7. Shut down and power off VM
8. Power up VM
9. Change CDROM drive letter to Z:
10. SNMP Service, Agent tab: Uncheck Physical checkbox. Uncheck Datalink checkbox.
11. Delete HP/Compaq NICs if they exist. Only the VMware Accelerated AMD PCNet NIC should remain
12. Rename Local Area Connection xx to Local Area Connection 1
13. Ensure correct TCP/IP setting for new vNIC
14. Change ACPI Multiprocessor PC HAL to Advanced Configuration and Power Interface (ACPI) PC HAL. This is needed for proper CPU idling. The yellow image was based off a SMP HAL and our VM is not vSMP enabled. Don’t reboot yet.
15. Perform the following to allow Windows to completely remove locally cached user profiles (the VMware file \Documents and Settings[username]\Application Data\VMware\hgfs.dat prevents this without this tweak)
Access the Windows Registry. Choose Start > Run, then type regedit. The Registry Editor window opens.
Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\Order\.
Right-click ProviderOrder and choose Modify. In the Edit String Value dialog box, edit the value data string and remove the characters ,hgfs (including the leading comma)
For example, if the value data string contains LanmanWorkstation,hgfs then change it to LanmanWorkstation
If the value data string contains only hgfs, then erase it and leave the value data string empty.
Click OK.
Close the registry editor. Choose File > Exit
16. Reboot
17. Login. A hardware discovery may be made requiring another reboot.
18. Reboot
19. Clear the contents of all three event logs (Application, System, and Security)
20. Shut down the VM.
21. Boot the VM from the Windows Server 2003 Command Console or ERD Commander 2005 and delete C:\pagefile.sys if it exists before snapping image. This will conserve image size. It is possible this file may not already exist which is fine. See
http://support.microsoft.com/kb/255205
Making the VM portable to other ESX Servers:
22. The following steps are optional. To compress the VM and make it portable for moving in and out of the lab or moving across the network to a different ESX host, follow these instructions
23. Configure floppy and CD-ROM devices:
a. Detach any attached floppy and/or CD-ROM devices
b. Set floppy and CD-ROM devices to host based
24. Log on to the ESX server as root
25. Change directory to the location of the VM to be compressed (ie. --root@mnesx1 /--# cd /vmfs/volumes/lab_msa_1/psbase01/)
26. On the ESX host where the new P2V’d VM exists, the following files can be deleted:
a. *.log (rm *.log –f)
b. *.nvram (rm *.nvram –f)
27. On the ESX host, edit the .vmx file and remove the line similar to the following:
sched.swap.derivedName = "/vmfs/volumes/414e3788-7b3ab862-4bf0-000802b03d6c/psbase01/psbase01-43ab3dd5.vswp"
28. Now go up one level (--root@mnesx1 /vmfs/volumes/lab_msa_1/psbase01--# cd ..)
29. --root@mnesx1 /vmfs/volumes/lab_msa_1--# ll -h
30. You should see the directory where the VM lives
drwxr-xr-x 1 root root 1.1K Dec 3 10:21 psbase01
drwxr-xr-x 1 root root 3.0K Dec 2 20:55 sqlprod1
drwxr-xr-x 1 root root 1.6K Dec 2 20:55 sqlprod2
drwxr-xr-x 1 root root 1.8K Dec 2 20:43 labadwfb03
drwxr-xr-x 1 root root 1.9K Dec 2 20:33 labsqltest
drwxr-xr-x 1 root root 2.5K Dec 2 20:24 mndhcp
drwxr-xr-x 1 root root 1.2K Nov 28 15:29 isos
drwxr-xr-x 1 root root 1.6K Dec 2 21:05 Windows Server 2003 Enterprise Gold
drwxr-xr-x 1 root root 1.6K Dec 2 20:53 Windows Server 2003 Standard Gold
31. Create the compressed tarball (--root@mnesx1 /vmfs/volumes/lab_msa_1--# tar -czf psbase01.tar.gz psbase01/)
32. After considerable amount of time (it’s compressing 37GB), the compression procedure will finish and you should see the single .tar.gz file sitting in the directory you’re in currently
33. --root@mnesx1 /vmfs/volumes/lab_msa_1--# ll -h
drwxr-xr-x 1 root root 1.1K Dec 3 10:21 psbase01
-rw-r--r-- 1 root root 3.4G Dec 3 10:54 psbase01.tar.gz
drwxr-xr-x 1 root root 3.0K Dec 2 20:55 sqlprod1
drwxr-xr-x 1 root root 1.6K Dec 2 20:55 sqlprod2
drwxr-xr-x 1 root root 1.8K Dec 2 20:43 labadwfb03
drwxr-xr-x 1 root root 1.9K Dec 2 20:33 labsqltest
drwxr-xr-x 1 root root 2.5K Dec 2 20:24 mndhcp
drwxr-xr-x 1 root root 1.2K Nov 28 15:29 isos
drwxr-xr-x 1 root root 1.6K Dec 2 21:05 Windows Server 2003 Enterprise Gold
drwxr-xr-x 1 root root 1.6K Dec 2 20:53 Windows Server 2003 Standard Gold
34. At this point, the single .tar.gz file can be safely copied to a USB drive or burned to DVD (assuming it fits) for portability to other ESX Servers. To extract the tarball, use the command tar -xzvf filename.tar.gz Due to the way we packaged the tarball, this command will create whatever directory structure exists in the tarball. Referencing the example above, a folder called psbase01 will be created and the file contents will be placed in that folder.
Do you run your citrix servers free floating with other VMs or on dedicated boxes ?
The Citrix VMs are free floating - VMware DRS puts them wherever it feels like putting them.
Jason Boche
VMware Communities User Moderator