Machine Creation Services

Infrastructures are not static; they evolve to satisfy new business requirements, offer new applications, or support new users.

A common task that every Citrix administrator has to face is to deploy, as fast as he or she can, new worker servers. Citrix offers the following two technologies to automatically provide new servers, starting with a master image:

• Provisioning Services (PVS)
• Machine Creation Services (MCS)

Provisioning Services is a classic solution, available for years and widely used in many XenApp and XenDesktop infrastructures.

Servers are delivered from a Provisioning Services virtual disk (vDisk), imaged from a master device. Target servers are configured to perform a network boot and receive the vDisk image from the PVS server. vDisks are usually configured in the read-only mode; local changes are discarded at every reboot.

Provisioning Services works with almost any device and does not require any virtualization technology. The target servers can be physical, virtual, or a mix of both.

Machine Creation Services was introduced in XenDesktop 5, and now, with the adoption of FlexCast Management Architecture, it is also available for XenApp infrastructures.

It leverages on a virtualization technology to deploy and control the full life cycle of virtual servers and virtual desktops, starting with a master virtual machine.

PVS versus MCS

Both Provisioning Services and Machine Creation Services are enterprise solutions included in XenApp 7.5.

PVS is the only choice if you're going to implement physical targets. MCS integrates on the hypervisor layer and therefore cannot be used on physical servers.

PVS is usually preferable in a mixed infrastructure that also includes a large number (less than 2,000) of virtual desktops. PVS is also preferable because MCS requires more IOPS (about 21 percent) than PVS and potentially more storage space.

Persistency, that is, the need to maintain changes for different targets forced the use of MCS in the past. The reason was that PVS prior to version 6.0 only had server-side caching that caused several performance issues. Now, both the technologies offer client-side caching.

For small and midsize XenApp infrastructures, with only virtual servers, my choice is MCS now; this is because of the following reasons:

• It does not require any dedicated servers like PVS does
• It takes advantage of virtualization features such as snapshots
• It is integrated in Citrix Studio (PVS requires a dedicated console)
• It does not use the network to deploy the servers (PVS can generate high traffic on the network)

IOPS and IntelliCache

Citrix documented that MCS generates approximately 45 percent of more peak IOPS compared to PVS. The reason is that during the boot and logon phases, all the virtual machines created by MCS access a shared copy of the master image, and servers that are provisioned by PVS get the needed data through the network instead.

The typical R/W (read/write) ratio for Windows MCS machines during the various phases is as shown in the following diagram:

The R/W ratio for Windows machines, courtesy: Project VRC

If you're using XenServer (from Version 5.6 Feature Pack 1), you take advantage of the IntelliCache feature to reduce the number of IOPS performed on your storage.

After the first start of a virtual machine, IntelliCache uses the local storage cache of the server to cache blocks of the base image as far as they are accessed by the virtual desktop. If a second VM is started on the host, it uses the already cached bits on local storage and does not need to reach out to the shared storage.

IntelliCache also caches temporary and nonpersistent files; this means that a portion of a runtime read/write of each virtual machine might occur in a low cost server-attached storage rather than the consumption of IOPS resources of your storage area's network.

First, you have to enable IntelliCache when installing XenServer, choosing Enable thin provisioning (Optimized storage for XenDesktop).

Tip

You can also enable thin provisioning on an existing XenServer; refer to Citrix's installation guide (http://support.citrix.com/article/CTX129387).

IntelliCache is disabled by default in XenApp or XenDesktop. When you are adding a XenServer host and are prompted for the type of storage to use, select Shared; then, select Use IntelliCache to reduce load on the shared storage device, as shown in the following screenshot:

Enabling IntelliCache when adding a XenServer host to Citrix Studio

Note

VMware vSphere 5 includes a feature named Content-Based Read Cache (CBRC) that is similar to IntelliCache. With this feature, you can have the host hypervisor scan the storage disk blocks to generate digests of the block contents. When these blocks are read into the hypervisor, they are cached in the host-based CBRC, and subsequent reads of blocks with the same digest are served from the in-memory cache directly.

Even if CBRC is not officially supported by Citrix, it can be used to optimize IO workloads when using MCS with VMware virtual infrastructures.

Requirements

Machine Creation Services require one of the following virtualization technologies:

• Citrix XenServer 6.0.2 or higher
• VMware vSphere 5.0 update 2 or higher
• System Center Virtual Machine Manager 2012 or higher (includes any version of Hyper-V that can register with the supported System Center Virtual Machine Manager versions)

Machine Creation Services can also deploy virtual machines on Amazon Web Services (AWS) and Citrix CloudPlatform.

The following virtualization technology and storage-type combinations are supported; combinations in bold are recommended:

Virtualization technology	Local disks	NFS	Block storage
XenServer	Yes	Yes	Yes
VMware	Yes	Yes	Yes
Hyper-V	Yes	No	Yes (with cluster-shared volumes)

Connecting to the virtual infrastructure

MCS requires a connection to your virtual infrastructure.

Open Citrix Studio and select Hosting on the left-hand side pane. From the Actions pane, click on Add Connection and Resources.

Select the hypervisor you're using and enter the credentials for the connection, as shown in the following screenshot:

Adding a new connection

Select the resources (cluster, network, and storage) for the new connection and complete the wizard.

Tip

If you're using self-signed SSL certificates in your VMware vCenter, you might encounter an error message: Cannot connect to the vCenter server due to a certificate error.

The SSL certificate of the default Certification Authority (CA) must be added to Certificate Store of your server, as shown in the following steps:

1. Connect to your vCenter server and copy the cacert.pem file from C:\ProgramData\VMware\VMware VirtualCenter\SSL.
2. Open Microsoft Management Console (mmc.exe) in your controller server and add the Certificates snap-in to manage certificates for the local computer account.
3. Import the cacert.pem file in the Trusted Root Certification Authorities folder, as shown in the following screenshot:
   

   Adding a Trusted Root Certification Authorities certificate

Creating a new master image

A master image is a template that you can use to deploy your environment. It should contain all the applications and resources you want to deliver using XenApp.

Note

If you're using Microsoft KMS (Key Management Services) to manage Windows and Office licenses, you don't need to manually launch the rearm process (slmgr.vbs) or run the sysprep.exe command on the master image.

Create a new virtual machine using the management tool for your hypervisor and install the operating system, including service packs and updates. The number of vCPUs and the amount of memory you assign to the virtual machine is not critical; you can change these settings when you create a machine catalog. It's important to choose the correct amount of disk space, including the space that will be required for applications and users' data (if you're not using a profile management solution) because it cannot be changed later.

Install the integration tools for your hypervisor (VMware Tools, XenServer Tools, and Hyper-V Integration Services); then, install the Citrix Virtual Delivery Agent (VDA).

When installing VDA, select Create a Master Image, enter the addresses of your Delivery Controllers, and enable the Optimize performance feature, as shown in the following screenshot:

Enabling the Optimize performance feature

Install and configure the applications you're going to deliver using XenApp and any third-party tools needed in your infrastructure, such as antivirus software or management agents. Make sure those tools can be installed in machines deployed from a single image; some agents create a unique identifier (UUID) when you install them, and if all your servers are created from a single installation, they'll have the same UUID. Sometimes, you might need to write a startup script for your servers that will change the agent's UUID (usually stored in Windows Registry).

When the master image is complete, Citrix recommends that you create a snapshot of it and name the snapshot so that you can identify the master image in future. If you specify a master image rather than a snapshot when creating a machine catalog, Studio creates a snapshot for you but you cannot name it.

Creating a machine catalog

Machine catalogs are collections of physical or virtual machines that you can assign to users.

A machine catalog can be configured to use MCS to create the number of VMs you specify based on the master image you created in previous sections.

In Citrix Studio, select Machine Catalogs on the left-hand side pane and then click on Create Machine Catalog in the Actions pane.

Select the appropriate operating system for your machine catalog; if you're going to deliver applications using XenApp, choose Windows Server OS.

You're now prompted to select the machine management tool that your catalog will use. Choose Machines that are power managed (this means you want to use a machine management tool) and Deploy machines using Citrix Machine Creation Service, as shown in the following screenshot:

Selecting MCS to deploy Catalog's machines

Select the virtual machine (or one of its snapshots) that will become the master image of your catalog:

Define the number of virtual machines needed in the new catalog along with their resources, as shown in the following screenshot (the number of vCPUs and the amount of memory). Note that the hard disk size cannot be changed.

Defining the virtual machines for the new catalog

The new virtual machines require an Active Directory computer account. If you have access to an Active Directory domain admin account, you can allow Studio to create new accounts for you by performing the following steps:

1. Select the location where the computer accounts will be created. I suggest that you should create a dedicated Organizational Unit (OU) in your domain; a dedicated OU also allows you to apply specific policies to the servers from within.
2. Specify the account-naming scheme.

If you can't create accounts in your Active Directory, you can select unused accounts that already exist (or that someone created for you), or you can import a .csv file that contains the list of account names in the following form:

[ADComputerAccount]
accountname1.domain
accountname2.domain

MCS can reset the account passwords, or if all the accounts share the same password, you can specify it.

Note

Account-naming scheme

This scheme can consist of fixed characters and a variable part defined by the # characters. A scheme can include only one variable part, and you can define it to be either numeric (1, 2,…) or alphabetic (A, B,…). The number of hash characters defines the minimum length of the variable region; for example, a naming scheme of WorkServer## will result in accounts called WorkServers01, WorkServer02 or WorkServerAA, WorkServerAB.

The characters not allowed in a naming scheme are \, / ,:, *, ?, ", <, >, |, ,, ~, !, @, $, %, ^, &, ', (, ), {, }, and _.

If your master image has more than one network card, you can enable/disable the network cards and associate them to the correct virtual network.

At the end of the wizard, MCS copies the master image to the datastores you configured as resources for the connection to your virtual infrastructure and creates the requested number of virtual machines.

Machine Catalog is now ready to deliver applications, as shown in the following screenshot:

Machine Catalog managed by MCS

You can use the Test Machine Catalog action to verify that the new Machine Catalog is properly configured.

Updating machines

If you need to perform an update (for example, install OS patches) or install new applications, you can perform the requested changes on the master image, take a new snapshot (so you can always return to the previous image if something goes wrong), and with a configurable rollout strategy, update the catalog's virtual machines based on the new snapshot.

After having updated the master image, choose the catalog to be updated and select Update Machines from the Actions pane.

Select the new snapshot and define a rollout strategy, either in the following situations:

• On the next shutdown
• Immediately (shut down and restart the machine now)

If you chose Immediately, you can program a distribution time (that is the interval within which the machines are restarted) and send a notification message to the users (for example, warning them to close all the running applications).