By: Andy Paul
One of the often overlooked features of XenApp is truly understanding the load evaluators. As a consultant, I commonly see environments using only the Default Load Evaluator. If I am lucky, they might be using the Advanced Load Evaluator. Rarely do I find organizations actively monitoring or customizing their load evaluators.
Load Evaluators have not changed much since Presentation Server days, but amazingly they are not commonly optimized. Every environment and every workload is different, so whichever load evaluator is implemented may vary, but they should be customized and monitored.
Here is a screen shot of the XenApp 6 Advanced Load Evaluator, which is now the default assignment. It creates a load based on CPU Utilization, Load Throttling, Memory Usage and Page Swaps. The Default Load Evaluator (assigned by default in XenApp 5 and prior versions) measures Server User Load.
I generally recommend creating a custom load evaluator based on resources, usually CPU Utilization, Load Throttling, Memory Usage and possibly Server User Load. This way, I can spread the load across servers based on number of users, resource loads and help prevent login storms.
Understanding Loads
But assigning a Load Evaluator is only part of the battle. You must also understand what and how that load is calculated. A simple QFARM /LOAD will show you server loads (or QFARM /LTLOAD to see the server resource load without calculating Load Throttling.) However, if you are using a load evaluator with multiple components, what is causing the load? The base algorithm for establishing actual load is Highest_Load + (Average_Other_Loads * .1).
Assuming you have a load evaluator monitoring CPU Utilization, Memory Usage and Load Throttling, and you see a server with a 7800 load value, it may be dangerously close to 10000 (Full Load) since that 7800 is not the aggregate of all loads, but reflective of the highest load, which could be close to reporting full. In this case, perhaps that server is running at 78% Memory Usage, with a cap set to 80% in the load evaluator… one more process may send it over the edge.
Detailed Load Monitoring
So what can you do about it? Knowing your environment is key, as is monitoring actual loads and adjusting evaluators or adding capacity as necessary. To this end, you can run real-time analysis of the various components of a load evaluator using the QUERYDS tool from Citrix. Additional information is available under CTX112082. These were originally published for Presentation Server 4.0, but are still valid for all editions, including XenApp 6. Please note, the output from QUERYDS will be hex values, and will need to be converted. Most applications include a Hex-Decimal conversion function, or you can use a free online converter such as http://easycalculation.com/hex-converter.php
The following table identifies the code values of the different load evaluator properties:
a -- Application User Load
2 -- Context Switches
1 -- CPU Utilization
7 -- Disk Data l/O
8 -- Disk Operations
9 -- IP Range
d -- Load Throttling
3 -- Memory Usage
4 -- Page Faults
6 -- Page Swaps
5 -- Scheduling
b -- Server User Load
Using this information, take the sample below; consisting of three servers:
Server TEST02 has a load of 1610 (HEX 64a). This load is comprised of:
- Server User Load: 2 (b:2)
- Load Throttling: 0 (d:0)
- Memory Usage: 16 (3:10)
- CPU Utilization: 0 (1:0)
These are percentages of 100, so a Memory Usage load of 16 is a load value of 1600. Load Throttling is not calculated since there is no current logon event. That leaves the average of Server User Load and CPU Utilization (200+0)/2*.1 = 10. This makes the total load value of 1610.
Conclusion
Now that you have a way to view the load components (QUERYDS) and an understanding on how to interpret the results, these values can be read and automated into a monitoring solution - either real-time or historical. Once a baseline is established, alerts can be generated as values approach full loads. Based on this information, you can then decide if you should modify your evaluators or add capacity.
Additional Reading:
Read more!
By: Andy Paul
When XenDesktop Desktop Studio is configured, a hosting infrastructure and storage system is defined. This hosting infrastructure can be Citrix XenSerspver, VMWare ESX/vSphere, or Microsoft Hyper-V. Storage for use by XenDesktop is also defined, which can be local storage or shared storage. In a production vSphere environment, shared storage defined as VMWare Datastores is preferred.
When using Machine Creation Services (MCS) in XenDesktop 5 Desktop Studio, a Master Image is identified when a Catalog is created. MCS Catalogs can be designed for Dedicated or Pooled virtual desktops. Pooled Assignments can be set for static assignment or random access.
Dedicated Catalog virtual desktops retain all changes, including software installations and local data, in a local difference disk. Pooled Catalog virtual desktops do not retain changes, the difference disk is reset upon reboot, leaving only a copy of the master image. However, when using pooled desktops, the base image can be updated allowing changes from the master disk to be replicated to the deployed VMs, providing for centralized patch and application management. Each deployed image, whether pooled or dedicated, will also contain an identity disk; all deployments utilize thin provisioning.
The following chart highlights the benefits of each type of XenDesktop Catalog:
During this test implementation, two Dedicated Catalogs are used to pilot XenDesktop 5. One catalog will be based on Windows XP, the other catalog will be based on Windows 7. These catalogs and the dedicated machines will be assigned to Desktop Groups for different business units.
Master Image Utilization
Once a master image is identified as part of the Catalog creation, a private-use clone of the VMDK is created for use by the catalog machines. This cloned disk is separate from the Master Image VM, allowing that VM to be updated or deleted with no impact on the MCS deployed virtual desktops.
This master image clone is copied to each Datastore defined during XenDesktop site setup. This site definition can be modified to include additional storage as it becomes available. If five datastores are defined the clone will be created on the first Datastore and then copied to the remaining four.
Each catalog is linked to its own master image clone. If multiple catalogs are defined, then multiple master clones will be generated. Any additional machines created within a catalog will use the defined master image. A master image can be changed to a different disk using the following command in PowerShell: Publish-ProvMasterVmImage (click here for an example of using this command if necessary.) This change would only impact new machines created in the catalog, not existing machines already generated.
Impact on Storage
Since MCS uses thin-provisioning, using Pooled or Dedicated desktops should require less storage than existing VM creations. On vSphere, the MCS service creates a snapshot for each VM called “Do Not Delete – Critical.” This snapshot is a reversion point back to initial deployment. For Dedicated desktops, additional snapshots can be created using vCenter’s Snapshot Manager functionality.
The master image, stored on each Datastore, becomes a private-use read-only VMDK for each MCS created VM. Depending on the NAS/SAN functionality, this image may be deduplicated or moved to high-utilization storage due to the increased read ratios.
For Pooled machines, the snapshot growth will be limited since it is reset at each reboot. Dedicated machine snapshots will grow over time as changes to the virtual desktop occur. It is recommended to incorporate profile management and data redirection where possible in either scenario to increase user flexibility and reduce data changes inside the images.
Determining Storage Requirements
Since MCS uses thin-provisioning, only the amount of space required is actually used, allowing for a potential of over-allocation of storage. When analyzing storage utilization, the key item to examine is the snapshot space utilized by each VM. Since the master image is shared, this is a “fixed” cost, where snapshot growth will be dynamic.
Please note, a snapshot can grow as large as the base disk, so if the master image is 40 GB in size, the associated snapshot for a dedicated machine can grow up to 40 GB in size; effectively doubling storage requirements if left unmanaged.
To see snapshot space utilized in vCenter, select the Datastore in question, select the Storage Views tab. This view will show the space used for each virtual machine as well as snapshot space used. For MCS created machines, the space used is misleading, since it is also counting the base image size. In the example below, the master image is 40 GB in size. For VXPXDTest002 (highlighted), the Space Used is 46.11 GB, but the actual space used is really 6.11 GB since 40 GB is for the shared master image. Of the 6.11 GB used, 4.09 GB is snapshot space.
To see more exact detail, you can browse the Datastore, examining the folder for VXPXDTest002, as shown below. Notice the total space used which is the active snapshot plus the memory swap file. The base image is stored in its own folder:
Sizing Wizard
Along with this analysis, I have created an Excel worksheet called MCS Sizing Wizard. This worksheet will help determine the size required for MCS deployed dedicated machines. The basic formulas are:
- Determine size requirements for master image:
- ..... [VMDK Size] * [# of Datastores]
- Determine size requirements for deployed virtual machines:
- ..... Create estimates for low, medium, and high usage snapshots
- ..... Per machine: [identity disk] + [RAM swap file] + [estimated size of snapshot]
- ..... Total VM sizing: [# of VMs] * [Per Machine Estimates]
- Determine total storage requirements
- ..... Most likely storage: [Expected VM storage] + [Master image storage]
Using the worksheet, creating 120 Windows 7 dedicated machines, spread across 5 datastores, with a 40 GB master VMDK, 4 GB RAM and an average snapshot size of 15 GB would use 2.4 TB of storage out of a maximum provision of 5.4 TB of storage. If using standard (existing) VMs, the same number of machines would use approximately 5.1 TB of space, for a net savings of 2.8 TB of utilized SAN storage. Using the worksheet, creating 120 Windows 7 dedicated machines, spread across 5 datastores, with a 40 GB master VMDK, 4 GB RAM and an average snapshot size of 15 GB would use 2.4 TB of storage out of a maximum provision of 5.4 TB of storage. If using standard (existing) VMs, the same number of machines would use approximately 5.1 TB of space, for a net savings of 2.8 TB of utilized SAN storage.
About this Article
The purpose of this article is to summarize the underlying architecture and impact of using Machine Creation Services in a pilot environment. This article is not intended to replace the XenDesktop Admin Guide or the XenDesktop PoC Implementation Guide.
The scope of this article is to help understand and manage the virtual machines created by MCS as well as understanding the storage requirements when using MCS. The actual amount of storage will grow over time as the snapshots grow and should be managed appropriately. Any sizing numbers are for illustrative purposes only and are no way intended as definitive calculations.
To help with the additional planning, design and optimization areas, it is recommended to utilize the XenDesktop Design Handbook Success Kit.
Additional References
XenDesktop 5 hosted-virtual desktop architecture series
XenDesktop 5 scalability: Site Capacity
PVS or MCS: We Are Talking About IOPS Again
PVS or MCS: Operations Is Important
Provisioning Services or Machine Creation Services: Big Picture Matters
XenDesktop 5 Virtual Machine Creation Services on vSphere 4.1
Read more!
By:Andy Paul
I've had the opportunity to work with the
XenServer 5.6 Beta and wanted to share a few of the new and improved features. With this latest release, Citrix XenServer is getting closer to the functionality of VMWare. I'm seeing more implementations of XenServer as it matures. Most of these implementations generally for new customers who do not have a virtualization initiatives or customers who are "Citrix shops." However, I do see more and more VMWare customers I work with who are adopting XenServer in parallel to their existing infrastructure.
There is no denying that vSphere is the more mature and more robust product. Just like there is no denying that it is more expensive and can be more complex. I generally say that XenServer will get you 90% of the way there at a much lower price tag, and for most customers that is plenty. With these new updates, that margin of difference is decreasing.
XenServer 5.6 Beta includes a number of new features and ongoing improvements. The full list can be seen here, but today, I want to focus on Dynamic Memory Control. This is the feature that peaks the most interest of administrators.
Personally, I have never been a fan of over-allocating memory. Virtualization allows dynamic use of resources, but those resources are not limitless. However, there are times when you need to use overallocation, such as lab, PoC, and Test/Dev environments. Using the DMC in XenServer 5.6 through the XenCenter console is easy and intuitive. As you can see in the picture below, you can monitor the "big picture" of the host, as well as the individual impact on each VM -- so you really know how and where your memory is being used. The first image below show the memory allocation without DMC configured (the host only has 4 GB of RAM); the second image shows the memory allocations after adjusting the memory ranges (the host is now over committed -118%)
Note, the VMs are running in a variety of memory configurations:
- XDPOCDDC VM is configured to run between 1024 and 2048 MB, the Guest OS (Win 2003) see 2048 available RAM
- XDPOCWINXP1 was configured at 512 static, I modified it to range between 512 and 768. Because it was not using DMC before this change, a reboot is required to complete the RAM increase
- XDPOCWINXP2 was configured at 1024 static, I modified it to range between 768 and 1024.
- XDPOCWINXP3 is still configured for 512 static (min and max are the same value)
Per Citrix -- "Dynamic Memory Control. This feature can increase the number of VMs per host by permitting the memory utilization of existing VMs to be compressed so that additional VMs can boot on the host. Once VMs on that host are later shut down or migrated to other hosts, running VMs can reclaim unused physical host memory. Dynamic Memory Control is enabled by defining minimum and maximum memory settings for virtual machines."
Basically, this is the over-commit VMWare has been long known for. Dynamic Memory Control (DMC) provides the following benefits:
- Memory can be added or removed without restarting the VM, providing a seamless experience to the user.
- When host servers are full, DMC allows you to start more VMs on these servers, reducing the amount of memory allocated to the running VMs proportionally.
- As memory requirements on the host change, DMC will auto-adjust the memory of running VMs, but will keep the memory within a range specified by the administrator.
For each VM the administrator can set a dynamic memory range - this is the range within which memory can be added/removed from the VM without requiring a reboot. When a VM is running the administrator can adjust the dynamic range. XenServer always guarantees to keep the amount of memory allocated to the VM within the dynamic range; therefore adjusting it while the VM is running may cause XenServer to adjust the amount of memory allocated to the VM.
DMC allows you to configure dynamic minimum and maximum memory levels – creating a Dynamic Memory Range (DMR) that the VM will operate in. In XenCenter, this can be configure to a fixed memory, or a range. The range can be defined manually or using the graphical tool to slide the setting points. This is analogous to Memory Reservations in VMWare.
DMC Behavior: Automatic VM squeezing
If a new VM is started on a XenServer with "full" memory already assigned the running VMs have their memory 'squeezed' to start new ones. The required extra memory is obtained by reducing the existing running VMs proportionally within their pre-defined dynamic ranges. Of course, if a VM is set to Fixed Memory and the Host is "full," the an "out of memory" failure will occur.
When DMC is enabled, and the host's memory is plentiful, then all running VMs will receive their Dynamic Maximum Memory level. When a host's memory is scarce, all running VMs will receive their Dynamic Minimum Memory level (or close too it). Again, the memory sharing is proportional.
Please note, the Dynamic Memory Control requires a Citrix Essentials for XenServer license. As of XenServer 5.6, this is centrally managed via the Citrix License Management Console. You can download XenServer 5.6 Beta as well as the require Essentials License files here (MyCitrix Login is Required).
Next Installment: Role Based Security and XenCenter Changes
Read more about XenServer
Read more!
By:Andy Paul
Running XenServer, you may run into instances where you needed to directly mount and boot a VHD file in XenServer. I have encountered this several times, including migrating a virtual server from Hyper-V to XenServer as well as updating XenTools and Provisioning Tools for Citrix-based deployments.
The following process will take you through preparing a storage repository in XenServer and importing your VHD file for direct boot.
PART I - Creating an EXT3 DRIVE
VHD files require an NFS or EXT3 formatted storage repository. The standard install of XenServer creates a local storage repository using LVM format. You can destroy this and create an EXT partition instead. In my XenServer farms where I am using shared storage, I like to create at least one host with an EXT drive for flexibility.
Please note, this will also destroy ANY VMs on that partition, so proceed with caution.
- Connect to your XenServer command line interface. You can use XenCenter for this, but I like to use PuTTY for the copy/paste and scroll features.
- Collect your necessary information:
- Find the default SR device ID (DEFAULT_SR_PHYSDEVS=) In a single disk system this should be /dev/sda3: # cat /etc/xensource-inventory
- Determine the UUID for your default SR: # xe sr-list type=lvm
- Determine the UUID your default SRs PBD your default SR: # xe pbd-list sr-uuid=your SR UUID (from step 2b above)
- in a multi-host pool, you want to make sure you reference to correct host. You can find this results step 2a under the label INSTALLATION_UUID= or run the command: # xe host-list
- Destroy the existing LVM partition:
- Disconnect the default SR: # xe pbd-unplug uuid=your PBD UUID (from 2c above)
- Remove the default SR: # xe sr-destroy uuid=your SR UUID (from 2b above)
- Create EXT partition
- # xe sr-create content-type="Local SR" host-uuid=[YOUR HOST ID] type=ext device-config-device=[YOUR DEVICE] shared=false name-label=" Local EXT3"
- NOTE: This command takes a few minutes to run and will return the UUID of the new partion when complete. Also, if you are on a single host system, you can tab after host-uuid= to poplate the host-id value
- Example Command: # xe sr-create content-type="local SR" host-uuid=0d1c9ba5-2304-46d9-8b75-459f41fb7f8a type=ext device-config-device=/dev/sda3 shared=false name-label="Local EXT3"
YOUR NEW SR IS READY TO USE AND SHOULD APPEAR IN XENCENTER
However, if you need to define a default SR, such as in a single host / single drive system, use the following:
- Set the default SR: # xe pool-param-set default-SR=YOUR NEW SR UUID uuid=xxxxxxxx
- Set your SR as the default location for suspended VM images: # xe pool-param-set suspend-image-SR= YOUR NEW SR UUID uuid=xxxxxxxxxx
PART II - COPYING VHD FILES TO XENSERVER
- Connect to your target XenServer with an SCP Utility to copy the files. I have used WinSCP with good results.
- Copy to /var/run/sr-mount/[uuid of ext3 SR create in Part 1]
- If using explorer mode of WinSCP, you can drag and drop your files to initiate the copy
IMPORTANT NOTE: MAKE SURE YOU COPY YOUR FILES TO THE CORRECT PARTITION!!!! (not the Root!)
PART III - DIRECT MOUNTING
- In XenCenter, create a new VM with setting similar to the configuration of the VHD you copied over. DO NOT POWER ON THIS VM
- Using your SSH utility, note the name (UUID) of the new VHD file created by the wizard.
- Delete this file (UUID.VHD)
- rename your target VHD to this UUID name
- Power on your machine... and if everything goes right, VIOLA!
Your VHD is now imported and locally mounted. Once you power on the VM, you can update drivers, files, etc. If you plan on provisioning this server, connect a new blank vDisk and use XenConvert to capture an updated image. If you have enough storage space, I recommend keeping this image on the server for future updates/captures.
Additional Reading:
Read more!
By:Andy Paul
Overview
A growing trend in technology firms is
Bring Your Own Computer (BYOC or BYOPC). Of course organizations such as Microsoft, Google, Citrix and Cisco are embracing this -- which is to be expected. However, as workforces become increasingly mobile, and virtualization methodologies are further adapted in enterprises, BYOC will inevitably grow.
In the simplest terms, Virtualization is about decoupling. In server virtualization (vSphere, XenServer, HyperV), we decouple the server OS from the server hardware. With application virtualization (XenApp, AppV), we decouple software programs from the OS. With SAN and NAS storage, we long ago decoupled data storage from operating machines. With the advent of client hypervisors, we will being doing the same with PCs. All of these pieces are decoupled to create a more robust and flexible infrastructure. It is only logical, then, to decouple the enterprise organization from the desktop machine itself.
How it Works: Although the exact details will vary for each organization, the policy should detail minimum requirements (supported Operating Systems, anti-virus, support, etc) in exchange for a set IT budget or allowance. Beyond the basic standards, the employees are then free to buy or upgrade a system of their choosing. Citrix's BYOC pilot program provides for a $2,100 stipend every 3 years with certain constraints. A link to their case study is provided at the end of this article.
Benefits
- Employee Empowerment - Allowing users to select their own systems gives a sense of ownership. This aids in usability, support, and overall happiness. I know many IT employees who have better units at home than at the office and are sometimes frustrated by this. I've been in more than one environment where employees use their own equipment in addition, and sometimes in lieu of, corporate machines. This can support more than just power users, too. Apple enthusiasts can bring their MacBook Pro, Linux guys can get their Ubuntu on, even casual users can splurge on a new laptop bundle from Dell or HP. This allowance can also serve as an enticement for recruiting and retention.
- Reduced Costs - By giving users their OWN systems, the users are more likely to understand and support their own equipment. With OEM provided service and warranties, it also effectively out sources desktop support. This allows the organization to focus on items such as infrastructure and security, less on daily break/fix and maintenance.
- Flexibility - Users now have maximum flexibility for both professional and personal computing since they are one and the same. Being able to support BYOC also means being able to support a mobile workforce, so if someone is sick, they may be able to work effectively from home, thus maintaining company productivity.
Why Support BYOC
Along with the benefits previously listed, BYOC may be necessary to support the following scenarios:
- Mobile Workforce - due to the nature of a global economy and the current economic slowdowns, companies have benefited from a mobile workforce. This can reduce travel, relocation, and office expenses. It can also provide flexibility for the road warriors who are in the field or on client sites. Embracing this mobility creates an agile workforce.
- Re-purpose old equipment - a common cost savings point for VDI in general is the ability to re-use or re-purpose aging and obsolete hardware. Maybe that old P3 with 1gb RAM won't run Windows 7 effectively. However, as long as it can run the necessary client-side tools, you can connect to a virtual image and upgrade without changing the client hardware.
- Thin Client computing - other environments are ideal for thin client systems. Education, health care, manufacturing, to name a few industries, have already adopted thin clients as a way to reduce costs and standardize computing. These are commonly used for task workstations.
The infrastructure investment for BYOC supports these scenarios as well, allowing corporations to mix-and-match the end-points while maintaining a consistent computing environment. There's that flexibility again....
How to Do It
There are multiple ways to provide that flexible, agile, decoupled delivery as part of a BYOC adoption. Here are the most common ways, no one method is necessarily better than another. It greatly depends on each environment, and most environments will provided multiple options.
- Application Hosting - this is your basic Citrix XenApp (Presentation Server) or Terminal Services hosted application. The Applications run on central servers in a multi-user environment. This provides the greatest user-density and centralized administration but requires real-time connectivity.
- Application Streaming - common with XenApp, AppV, and a myriad of other providers; application streaming allows deployment of applications from centralized reposity. Depending on the methods used, this may be available both online (connected) and offline (disconnected). This decentralized the operations but maintains a central point of administration.
- Remote Desktop Services - is your classic Citrix or Terminal Services desktop. Instead of providing individual applications, an connection is made to the server desktop. From that central point, all availale applications can be accessed. This is generally used in a multi-user environment.
- Virtual Desktop - similar to Remote Desktops, except Virtual Desktops are typically used on a one user per machine basis and is a common way to deploy Windows 7 or other PC-based operating systems from a common image. Applications can be locally installed or streamed to the desktop image.
- Client-side Hypervisor - is a Type 1 or bare-metal hypervisor (such as VMware ESX or XenServer), but running on the client PC instead of a server. The advantage is to not only run multiple operating system, or even to have a personal and a work persona. The biggest advantage, in my mind, is to have a standard corporate image(s) which can be deployed and run locally.
Drawbacks
Obviously, there are drawbacks, or everyone would have adopted this a long time ago! Some of the issues to address are:
- Supporting Home Systems - once you allow users to buy/use their own systems, you are on the hook to support them. It will not matter if they have a 3 year, 24x7 4 Hour support contract, they will still expect YOU to solve their problems. Of course, instead of one manufacture/model/OS to support, you now are faced with hundreds. Policy may dictate they contact the OEM, but most likely, you will get called first. On top of that, what happens when they can't work at home... it become IT Support's problem.
- Cost of Infrastructure - this is biggest hurdle most companies will face. A solid BYOC program requires that you can support and enforce whatever standards (such as anti-virus) have been put in place as well as being able to maintain the delivery architecture (secure remote access, application delivery, etc).
- Security - the biggest risk is security. Not only anti-virus, but information security. Making sure that sensitive information and corporate secrets say secure. Granted, this is a concern for a normal network infrastructure, but even more so when you hand local system control to the end users. Nothing is 100% secure, but you better make sure your policies are clear and enforced.
Related Notes and Articles
Other Related Articles
Read more!
By:Andy Paul
There are numerous benefits for running Citrix XenApp on XenServer; including single vendor support, built-in optimizations, and integration features. However, what if you are working in a VMWare ESX environment? As a consultant or an internal engineer, you cannot always dictate the virtualization environment. The following are some tried and true best practices for optimizing XenApp on VMWare ESX.
The key is Memory Sharing and how VMWare allows overallocation of resources as opposed to XenServer. A key to optimizing performance is to NOT over-allocate RAM, which will reduce memory sharing between guests. The memory sharing/de-duplication is a great feature for infrastructure servers, but application/terminal services can suffer faults from the shared memory. Of course, if it were that simple, everyone would do it. Along with avoiding overallocation, the OS and services should be optimized. Finally, you should consolidate/isolate your Terminal Services workloads to common hosts -- in other words, dedicate ESX Hosts to run only XenApp. This will optimize VMWare's native memory sharing as well as streamlining I/O.
OS Optimization
Create a master VMWare TEMPLATE for each flavor of OS and XenApp you plan to install
- Align the drives - use DISKPART to create a 64k Partition, formatted using 32k allocation unit sizes
- 1 vCPU - assuming your application can run effectively in single CPU mode. Although there are many valid reasons to NOT do this, I recommend it because this reduces CPU %READY and CPU scheduling requirements by single threading the OS. Of course, if your app set requires multiple processors, or you risk pegging the single CPU, then this may not be an option.
- 2 GB RAM - this is a good starting point for baseline testing. Depending on the Host RAM and the app requirements, you may need to move this up or down accordingly.
- Set Page File Min and Max at 1.5 x RAM
- Installed latest VMTools, including the Memory Manager (aka the Balloon Driver)
- Please note, there are a lot of recommendation to disable this, but I believe that to be a fallacy:
- a lot of the information and recommendation out there is still based on ESX 2.x
- The Balloon Driver is a safety net, which should not be normally called on when designed properly
- when in doubt, and until proven otherwise, go with the standard package
- Disconnect/Disable the CD Rom - Windows guests poll CD devices quite frequently. When multiple guests try to access the same physical CD drive, performance suffers. Disabling CD devices in virtual machines when they are not needed alleviates this.
- Adjust the Disk timeout valie to the storage vendor's recommended: HKLM/SYSTEM/CurrentControlSet/Services/Disk/TimeoutValue = REG_DWORD Hex value 3c (60)
- Disable Last Time Access Atrribute for NTFS, this setting that keeps track of the last time a file was accessed. Removing the necessity for the system to keep reading and writing this information may speed up performance. The command is: fsutil behavior set disablelastaccess 1
- Disable screen savers
- Disable animations
- Disable USB
For more information on general performance tuning tips, see vi_performance_tuning.pdf
Services Optimization
Any and all services which are not needed should be DISABLED. These services consume Memory and CPU cycles, which are not usually noticeable on physical hardware, but are exacerbate in virtual environments.
- Citrix ActiveSync Service
- Citrix XML Service - enable this on your ZDCs, disable on your production app servers
- DHCP Client - if you are using static IP addresses
- Distributed File System
- Help and Support
- Human Interface Device Access
- Indexing Service
- Messenger
- Netmeeting Remote Desktop Sharing
- WebClient
- Windows Audio - unless, ofcourse, you truely need sound for your apps
- Wireless Zero Configuration
For more information on Windows 2003 Services, see TechNet.
Scaling Out
When virtualizing, it is key to remember to scale out, not up. Sure, 2 CPU and 4 GB RAM physical machine has more horse power than a 1 CPU / 2 GB RAM VM, but when you can fit 10 of those VMs on a single host, you get a much greater density while spreading the load around.
This is a larger hurdle with any virtualization project, to move past large amounts of CPU and RAM. Once you can accept that smaller may be better, you see the value of scaling out (more units) instead of up (larger units).
I have found 3gb is a nice "sweet spot," depending on your specific application requirements. If you are running on a physical Host of 48 GB, this could allow you to run 10-12 VMs, consuming 30-36 GB, leaving plenty of resources for the host, VMotion, and axillary servers if necessary.
My Rule of Thumb: 2 Citrix VMs = 1 Physical Citrix Server. Obviously, this will vary based upon the actual workloads and application demands. For the aforementioned 3gb Guest on a 48gb Host, you could replace 6 1U servers with a single host - saving 5U of valuable space (as well as power and cooling).
You will need to design your Load Evaluators according to your design. Because performance counters are abstracted in a virtual environment, I recommend using us custom evaluator based on Memory Utilization, CPU Utilization, Session Load, and Load Throttling.
Combine this design with the use of VMWare Templates, XenAppPrep, and/or Provisioning Services for rapid deployment and you will have a robust, efficient, and highly flexible VMWare environment for running XenApp.
Read more!
Microsoft Virtualization, Citrix, XENServer, Storage, iscsi, Exchange, Virtual Desktops, XENDesktop, APPSense, Netscaler, Virtual Storage, VM, Unified Comminications, Cisco, Server Virtualization, Thin client, Server Based Computing, SBC, Application Delivery controllers, System Center, SCCM, SCVMM, SCOM, VMware, VSphere, Virtual Storage, Cloud Computing, Provisioning Server, Hypervisor, Client Hypervisor.
