Machine Creation Services Primer – Part 2

In the first part of the Machine Creation Services Primer, we focused on the creation of Pooled-Random, Pooled-Static and Dedicated desktops. The process was very similar. However, at this point, items start to change and I want to focus on updating the master image, as this question usually comes up pretty quickly.

With Machine Creation Services, we have a master virtual machine somewhere within our environment. This master is what is used to create all of our MCS-provisioned desktops. On a weekly or monthly basis, many organizations will want to update the master image to include the latest updates. Easy enough, you just go to the master VM, and update it like any other VM. Once the master image is updated, you go into Desktop Studio and run the Update option. Here is where things start to be unique.

With pooled-random and pooled-static desktops, a new complete clone is created from the master image (just like when we create new VMs in Part 1). During reboot of the pooled-random and pooled-static desktops, a switch is made to tell the VMs to start reading from the latest cloned image. As the difference disks are deleted during reboot, there is no issue with the swapping of the master image. However, dedicated desktops are different.

With dedicated desktops, the difference disk does not get deleted on each reboot. This gives the users greater ability to customize their desktop. When we update the master VM image, the dedicated desktops are NOT told to use the latest cloned version of the master. Instead, they continue to use the cloned image from which they were created from. Only newly created dedicated desktops will use the latest image.

This is a very important point. If you use pooled-static or pooled-random desktops, updating the master image will update all virtual desktops based on that master image. If you use dedicated desktops, once they are created, their link to the master VM is severed. If you want to update the desktops, without losing all user changes, you must use your enterprise desktop management tools.

This process is important to note as I’ve had many people ask me why they have a lot of space being used by the master images. Let’s think about this from a storage perspective. Let’s say we are in the middle of a rollout with dedicated desktops. During the rollout, I’ve had to keep updating the master VM. Each time I update and create new dedicated desktops, that image is fully cloned and placed on my storage. If the image is 30GB in size (10GB thin provisioned), that means each storage repository containing the dedicated desktops will utilize 150GB (50GB thin provisioned) of storage space for the 5 difference images. As you continue and add more desktops with more updates, you will continue to increase storage space needs.

With dedicated desktops, managing the updates should be done with desktop management tools to the actual VMs and not the master image. The master image is there to help you quickly build desktops. It is not there to help you maintain dedicated desktops. However, with Pooled-Random and Pooled-Static desktops, the master image is there to help you with desktop maintenance and management.

Daniel – Lead Architect
XenDesktop Design Handbook


Machine Creation Services Primer – Part 1

I get a lot of questions about different components of XenDesktop. What are they? How do they work? Should I use it? I’ve decided to spend some cycles trying to provide information about some of these components. The first one we will hit is Machine Creation Services.

Machine Creation Services (MCS) is one option for desktop image delivery. It simply uses the hypervisor APIs (XenServer, Hyper-V, and vSphere) to create, start, stop, and delete virtual machines. Let’s say we want to create a catalog of desktops with MCS, you can pick either:

  • Pooled-Random: Desktops are assigned randomly. When they logoff, the desktop is free for another user. When rebooted, any changes made are destroyed.
  • Pooled-Static: Desktops are permanently assigned to a single user. When a user logs off, only that user can use the desktop, regardless if the desktop is rebooted. During reboots, any changes made are destroyed.
  • Dedicated: Desktops are permanently assigned to a single user. When a user logs off, only that user can use the desktop, regardless if the desktop is rebooted. During reboots, any changes made will persist across subsequent startups.

The creation process is as follows regardless if you are doing pooled-static, pooled-random or dedicated:

  1. Manual Step: First, have your master virtual machine created. This means you need to define the VM (vCPU, RAM, Disk space), install the OS, install the apps and make any configurations you want to be part of your user’s desktops. If you are thin provisioning the disk, you only use the amount needed up to your maximum amount define.
  2. Manual Step: Within Desktop Studio, you create a catalog for a pooled desktop and you have to select the master virtual machine you want to base other VMs on. This is the one you installed and configured with the OS and applications.
  3. Automatic Step: MCS creates a snapshot (thin) of the master VM unless you selected a snapshot, which will not create another snapshot. This uses minimal space
  4. Automatic Step: MCS creates a full copy of the point in time snapshot and places this on each storage repository defined in the host connection. This will utilize the amount of space used for your complete image.
  5. Automatic Step: MCS adds these desktops into Active Directory. This step creates the unique AD identities to be used later in the process
  6. Automatic Step: MCS creates the number of VMs specified in the create catalog wizard with two disks defined for each VM. However, in addition to the 2 disks for each VM, a master will also be be stored in the same storage repository. If you have multiple storage repositories defined, then each one will get the following types of disks
    1. The full snapshot, which is read-only and shared across the VMs just created. Each storage repository will get one. This is the same disk identified in step 4.
    2. A unique identity disk (16MB) used to provide each VM with a unique identity. Functionality within the XenDesktop Controllers creates the identity disks. Each VM gets an identity disk.
    3. A unique difference disk used to store any writes made to the VM. The disk is thin provisioned (if supported by the storage) and will increase to the maximum size of the base VM if required. Each VM gets a difference disk.
  7. Automatic Step: MCS adds these newly created desktops into Active Directory, utilizing the identities created

The differences appear when the desktops are put into production:

Pooled-Static Pooled-Random Dedicated
First logon User-to-desktop association stored permanently in the SQL Database User-to-desktop association stored temporarily in the SQL Database User-to-desktop association stored permanently in the SQL Database
Logout User-to-desktop association remains User-to-desktop association removed User-to-desktop association remains
Subsequent logons XenDesktop Controller directs the user to the permanent desktop association XenDesktop Controller picks any available desktop and temporarily stores the association in SQL Database XenDesktop Controller directs the user to the permanent desktop association
Reboot Differencing disk disconnects and a new disk is created. Old differencing disk deleted after startup complete Differencing disk disconnects and a new disk is created. Old differencing disk deleted after startup complete Differencing disk is permanent

In the upcoming Part II, we will focus on what happens when we need to make updates

Daniel – Lead Architect
XenDesktop Design Handbook

XenApp Virtualization Best Practices

One of the first questions when virtualizing XenApp is how many VMs to put on a server. Well, that was discussed in the Virtualize XenApp blog. Once you figure out how you plan to carve up the physical server, one of the next common questions is deciding which features of the hypervisor to enable/disable. For example, if I use XenServer, should I use the “Optimize for XenApp” setting? What about vSphere’s Transparent Page Sharing feature? And the big whopper, how should I allocate memory to my virtualized XenApp servers? Is it safe to use dynamic memory or am I safer to stick with fixed memory?

The following table is what Citrix Consulting has seen and recommends. By the way, if you want the entire discussion on virtualizing XenApp, then go to the XenDesktop Design Handbook and look in the Planning Guide section for XenApp Virtualization Best Practices.

Decision Justification Hypervisor
Overcommit CPU:No It is advisable not to allocate more vCPU than there are logical cores on within the given hardware. Experience has shown that greater levels of scalability are achieved by not overcommitting CPU. Hyper-VXenServer


Utilize Hyper-threading:Yes Newer processors have the ability to do hyper-threading, where each core is two logical cores. Utilizing hyper-threading in a XenApp environment has been shown to improve user density. Hyper-VXenServer


Disable ASLR: No As many organizations try to protect their XenApp servers from viruses, malware and other OS exploits, it is advisable to keep Address Space Layout Randomization enabled, which is the default setting. The functionality is included with Windows 2008, Windows 2008 R2, Windows Vista and Windows 7. Hyper-VXenServer


Enable Transparent Page Sharing:Depends on OS Enabling or disabling Transparent Page Sharing has not been shown to either help or hurt performance on newer systems (Windows 2008, Windows 2008 R2, Windows Vista and Windows 7). However, older systems (Windows 2003 and Windows XP) have benefited, mostly because the page sizes are smaller (4K), thus making it easier to share pages of memory. vSphere
Optimize for XenApp:N/A On systems utilizing pre-Nehalem processors, the XenServer setting “Optimize for XenApp” provided increased scalability. Since the release of the Nehalem processors, much of the functionality has been placed on the hardware so this particular XenServer setting can be ignored. XenServer
Disk Alignment: Yes As a host server will be running multiple instances of a server operating system, it is even more important to optimize the disk subsystem to improve performance and scalability as opposed to a system running a single operating system. Windows 2003 is misaligned with default installations. This should be corrected installation to help reduce storage impact. XenServerHyper-V


Memory Allocation:Fixed As users are dynamically load balanced across XenApp servers, memory usage between different virtual machines should be similar, helping negate the need for dynamic memory allocation techniques. Also, if VM migration strategies are used, this could cause memory overcommit resulting in aggressive paging and poor performance across all XenApp virtual machines. It is advisable to set fixed values for memory reservations for XenApp virtual machines. XenServer


Host Swapping: No In most environments, all XenApp servers are actively hosting users at the same time. Swapping out memory from one XenApp host will degrade performance for all virtual machines as the memory keeps getting transferred to/from disk. vSphere

Daniel – Lead Architect
XenDesktop Design Handbook

Virtualize XenApp

Here is a pretty common question… I want to virtualize my XenApp servers, how should I carve the physical server up? Should I use a bunch of small VMs or a few massive VMs?

First, you have to look at a few decision points:

  1. OS Scalability: This is more of an issue in Windows 2003.
  2. Operations: More VMs means more to manage, unless you use a single image management solution like Provisioning Services.
  3. Application Requirements: The applications will dictate how many vCPUs and how much RAM you need to fully utilize the VM. Over allocate one and you waste resources. Under allocate one and you waste resources.
  4. Flexibility: How easy is it to migrate active VMs to another server (discussed in the Big or Small VMs for XenApp blog)
  5. Licensing Costs: More VMs means more Microsoft licensing costs. In fact, you might end up moving from Standard to Enterprise or even Data Center.

When we take all of this stuff together, we end up with the following:

Sockets Cores / Socket Hyper-Thread Logical Cores / Socket Logical Cores / Server VM Count vCPU per VM RAM per VM
32-bit Operating Systems  (Windows 2003, Windows 2008)
2 2 No 2 4 2 VMs 2 vCPU 4 GB
2 2 Yes 4 8 2 VMs 4 vCPU 4 GB
2 4 Yes 8 16 4 VMs 4 vCPU 4 GB
4 2 Yes 4 16 4 VMs 4 vCPU 4 GB
4 4 Yes 8 32 8 VMs 4 vCPU 4 GB
64-bit Operating Systems (Windows 2003, Windows 2008, Windows 2008 R2)
2 2 No 2 4 2 VMs 2 vCPU 8 GB
2 2 Yes 4 8 2 VMs 4 vCPU 16 GB
2 4 Yes 8 16 2 VMs 8 vCPU 32 GB
4 2 Yes 4 16 4 VMs 4 vCPU 16 GB
4 4 Yes 8 32 4 VMs 8 vCPU 32 GB

I’ll probably hear a lot of comments for the 64bit systems with using bigger VMs and fewer of them. And those comments would be true. Windows 2008 64bit overcomes many of the bottlenecks we experienced with Windows 2003 32bit. But we are trying to have greater flexibility. We are trying to limit the impact of a VM failure. Bigger VMs means bigger impact if there is a failure.

How closely does your virtualized XenApp environment align? Or how about your plans? Are they retty close?

Daniel – Lead Architect
XenDesktop Design Handbook