Create machine catalogs

Note:

This article describes how to create catalogs using the Full Configuration interface. If you’re using Quick Deploy to create Azure resources, follow the guidance in Create catalogs using Quick Deploy.

Collections of physical or virtual machines are managed as a single entity called a machine catalog. All the machines in a catalog have the same type of operating system: multi-session OS or single-session OS. A catalog containing multi-session OS machines can contain either Windows or Linux machines, not both.

The Manage > Full Configuration interface guides you to create the first machine catalog. After you create the first catalog, you create the first delivery group. Later, you can change the catalog you created, and create more catalogs.

Overview

When you create a catalog of VMs, you specify how to provision those VMs. You can use Machine Creation Services (MCS). Or, you can use your own tools to provide machines.

• If you use MCS to provision VMs, you provide an image (or snapshot) to create identical VMs in the catalog. Before you create the catalog, you first use hypervisor or cloud service tools to create and configure the image. This process includes installing a Virtual Delivery Agent (VDA) on the image. Then you create the machine catalog in the Manage > Full Configuration interface. You select that image (or a snapshot of an image), specify the number of VMs to create in the catalog, and configure additional information.
• If your machines are already available (so you do not need images), you must still create one or more machine catalogs for those machines.

When using MCS to create the first catalog, you specify a host connection that you created previously. Later (after you create your first catalog and delivery group), you can change information about that connection or create more connections.

If a Cloud Connector is not operating properly, MCS provisioning operations (such as catalog updates) take much longer than usual, and the management interface’s performance degrades significantly.

Access images from Azure Shared Image Gallery

When selecting an image to use for creating a machine catalog, you can select images you created in the Azure Shared Image Gallery. These images appear in the list of images in the Master Image screen of the Machine Catalog Setup wizard.

For these images to appear, you must:

1. Configure a Citrix Virtual Apps and Desktops site.
2. Connect to the Azure Resource Manager.
3. In the Azure portal, create a resource group. For details, see Create an Azure Shared Image Gallery using the portal.
4. In the resource group, create a Shared Image Gallery.
5. In the Shared Image Gallery, create an image definition.
6. In the image definition, create an image version.

RDS license check

Creation of a machine catalog containing Windows multi-session OS machines includes an automatic check for valid Microsoft RDS licenses. The catalog is searched for a powered-on and registered machine to perform the check on.

• If a powered-on and registered machine cannot be found, a warning is displayed, explaining that the RDS licensing check cannot be performed.
• If a machine is found and an error is detected, Manage > Full Configuration displays a warning message for the catalog containing the detected issue. To remove an RDS license warning from a catalog (so that it no longer appears in the display), select the catalog. Select Remove RDS license warning. When prompted, confirm the action.

VDA registration

A VDA must be registered with a Cloud Connector to be considered when launching brokered sessions. Unregistered VDAs can result in underutilization of otherwise available resources. There are various reasons a VDA might not be registered, many of which you can troubleshoot. Troubleshooting information is provided in the catalog creation wizard, and after you add a catalog to a delivery group.

In the catalog creation wizard, after you add existing machines, the list of computer account names indicates whether each machine is suitable for adding to the catalog. Hover over the icon next to each machine to display an informative message about that machine.

If the message identifies a problematic machine, you can either remove that machine (using the Remove button), or add the machine. For example, if a message indicates that information cannot be obtained about a machine (perhaps because it had never registered), you might choose to add the machine anyway.

For more information about VDA registration troubleshooting, see CTX136668.

MCS catalog creation summary

Here’s a brief overview of default MCS actions after you provide information in the catalog creation wizard.

• If you selected an image (rather than a snapshot), MCS creates a snapshot.
• MCS creates a full copy of the snapshot and places the copy on each storage location defined in the host connection.
• MCS adds the machines to Active Directory, which creates unique identities.
• MCS creates the number of VMs specified in the wizard, with two disks defined for each VM. In addition to the two disks per VM, a master is also stored in the same storage location. If you have multiple storage locations defined, each gets the following disk types:
  • The full copy of the snapshot (noted above), which is read-only and shared across the just-created VMs.
  • A unique 16 MB identity disk that gives each VM a unique identity. Each VM gets an identity disk.
  • A unique difference disk to store writes made to the VM. This disk is thin provisioned (if supported by the host storage) and increases to the maximum size of the master image, if necessary. Each VM gets a difference disk. The difference disk holds changes made during sessions. It is permanent for dedicated desktops. For pooled desktops, it is deleted and a new one created after each restart.

Alternatively, when creating VMs to deliver static desktops, you can specify (on the Machines page of the catalog creation wizard) thick (full copy) VM clones. Full clones do not require retention of the master image on every data store. Each VM has its own file.

MCS storage considerations

There are many factors when deciding on storage solutions, configurations, and capacities for MCS. The following information provides proper considerations for storage capacity:

Capacity considerations:

• Disks

  The Delta or Differencing (Diff) Disks consume the largest amount of space in most MCS deployments for each VM. Each VM created by MCS is given at minimum 2 disks upon creation.

  • Disk0 = Diff Disk: contains the OS when copied from the Master Base Image.
  • Disk1 = Identity Disk: 16 MB - contains Active Directory data for each VM.

  As the product evolves, you might have to add more disks to satisfy certain use cases and feature consumption. For example:

  • MCS Storage Optimization creates a write cache style disk for each VM.
  • MCS added the ability to use full clones as opposed to the Delta disk scenario described in the previous section.

  Hypervisor features might also enter into the equation. For example:

  • Citrix Hypervisor IntelliCache creates a Read Disk on local storage for each Citrix Hypervisor. This option saves on IOPS against the image which might be held on the shared storage location.

• Hypervisor overhead

  Different hypervisors use specific files that create overhead for VMs. Hypervisors also use storage for management and general logging operations. Calculate space to include overhead for:

  • Log files
  • Hypervisor-specific files. For example:
    • VMware adds more files to the VM storage folder. See VMware Best Practices.
    • Calculate your total virtual machine size requirements. Consider a virtual machine containing 20 GB for the virtual disk, 16 GB for the swap file, and 100 MB for log files consuming 36.1 GB total.
  • Snapshots for XenServer; Snapshots for VMware.

• Process overhead

  Creating a catalog, adding a machine, and updating a catalog have unique storage implications. For example:

  • Initial catalog creation requires a copy of the base disk to be copied to each storage location.
    • It also requires you to create a Preparation VM temporarily.
  • Adding a machine to a catalog does not require copying of the base disk to each storage location. Catalog creation varies based on the features selected.
  • Updating the catalog to create an extra base disk on each storage location. Catalog updates also experience a temporary storage peak where each VM in the catalog has 2 Diff disks for a certain amount of time.

More considerations:

• RAM sizing: Affects the size of certain hypervisor files and disks, including I/O optimization disks, write cache, and snapshot files.
• Thin / Thick provisioning: NFS storage is preferred due to the thin provisioning capabilities.

Machine Creation Services (MCS) storage optimization

The Machine Creation Services (MCS) storage optimization feature is also known as MCS I/O:

• The write cache container is file-based, the same functionality found in Citrix Provisioning. For example, the Citrix Provisioning write cache file name is D:\vdiskdif.vhdx and the MCS I/O write cache file name is D:\mcsdif.vhdx.
• Achieve diagnostic improvements by including support for a Windows crash dump file written to the write cache disk.
• MCS I/O retains the technology cache in RAM with overflow to hard disk to provide the most optimal multi-tier write cache solution. This functionality allows an administrator to balance between the cost in each tier, RAM and disk, and performance to meet the desired workload expectation.

Updating the write cache method from disk-based to file-based requires the following changes:

1. MCS I/O no longer supports RAM only cache. Specify a disk size during machine catalog creation.
2. The VM write cache disk is created and formatted automatically when booting a VM for the first time. Once the VM is up, the write cache file mcsdif.vhdx is written into the formatted volume MCSWCDisk.
3. The pagefile is redirected to this formatted volume, MCSWCDisk. As a result, this disk size considers the total amount of disk space. It includes the delta between the disk size and the generated workload plus the pagefile size. This is typically associated with VM RAM size.

Enabling MCS storage optimization updates

When creating a machine catalog, the administrator can configure the RAM and disk size as follows:

• The machine catalog setup user interface of the web-based console:

  

To enable the MCS I/O storage optimization feature, upgrade the Delivery Controller and the VDA to the latest version of Citrix Virtual Apps and Desktops.

Note:

If you upgrade an existing deployment which has MCS I/O enabled, no additional configuration is required. The VDA and the Delivery Controller upgrade handle the MCS I/O upgrade.

With the MCS storage optimization feature enabled, you can configure the following settings when creating a catalog. These settings apply to both Azure and GCP environments.

• Configure the size of the disk and RAM used for caching temporary data.

• Select the storage type for the write-back cache disk.

  • For Azure, the following options are available: Premium SSD, Standard SSD, and Standard HDD. For more information, see Microsoft Azure Resource Manager cloud environments.
  • For GCP, the following options are available: Standard persistent disk, Balanced persistent disk, and SSD persistent disk. For more information, see Google Cloud environments.

• Choose whether you want the write-back cache disk to persist for the provisioned VMs. Select Enable write-back cache to make the options available. By default, Use non-persistent write-back cache disk is selected.

  • https://docs.microsoft.com/en-us/azure/storage/common/storage-introduction/
  • https://docs.microsoft.com/en-us/azure/virtual-machines/premium-storage-performance/
  • https://docs.microsoft.com/en-us/azure/storage/common/storage-redundancy/
• Use Use non-persistent write-back cache disk to control whether the write-back cache disk must not persist for the provisioned VMs in Azure. The disk is deleted during power cycles and any data redirected to the disk is lost. Using this option, you can use Azure temporary disk as storage because the option is suitable for non-persistent write-back cache disk. This reduces your storage cost and improves I/O performance. You can also use PowerShell. For details, see Using PowerShell to create a catalog with non-persistent write-back cache disk.

  • Use non-persistent write-back cache disk. To use this option:

    1. Select the check box Enable write-back cache.
    2. Enter a valid positive disk cache size in GB. The VM will not work properly if the size is too small.
    3. Select the option Use non-persistent write-back cache disk.
• Use Use persistent write-back cache disk to control whether the write-back cache disk persists for the provisioned VMs in Azure and Google Cloud Platform (GCP). By default, persistent write-back cache disk is disabled, causing the disk to be deleted during power cycles and any data redirected to the disk to be lost. Enabling this option increases your storage costs. You can also use PowerShell. For details, see Using PowerShell to create a catalog with persistent write-back cache disk.

  • Use persistent write-back cache disk. To use this option:

    1. Select the check box Enable write-back cache.
    2. Enter a valid positive disk cache size in GB. The VM will not work properly if the size is too small.
    3. Select the option Use persistent write-back cache disk.
• Use Retain system disk during power cycles to control whether to retain system disks for VDAs during power cycles. This behavior applies to both Azure and GCP environments.
  • Retain system disk during power cycles. By default, the system disk is deleted on shutdown and recreated on startup. This ensures that the disk is always in a clean state but results in longer VM restart times. If system writes are redirected to the RAM cache and overflow to the cache disk, the system disk remains unchanged. Enabling this option increases your storage costs but reduces VM restart times. Select Enable write-back cache to make this option available.
  • Retain VMs across power cycles. Select this option to retain your VM customization and to enable the VMs to be started through the Azure or GCP portal. Enable Retain system disk during power cycles to make this option available.

Note:

Azure ephemeral OS disk and MCS I/O cannot be enabled at the same time. For more information, see Azure ephemeral disk and Machine Creation Services (MCS) storage optimization (MCS I/O).

Conditions for Azure temporary disk to be eligible for write-back cache disk

You can use the Azure temporary disk as write-back cache disk only if all the following conditions are satisfied:

• The write-back cache disk must non-persist as the Azure temporary disk is not appropriate for persistent data.

• The chosen Azure VM size must include a temporary disk.

• The ephemeral OS disk is not required to be enabled.

• Accept to place the write-back cache file on Azure temporary disk.

• The Azure temporary disk size must be greater than the total size of (write-back cache disk size + reserved space for paging file + 1 GB buffer space).

Using PowerShell to create a catalog with non-persistent write-back cache disk

To configure a catalog with non-persistent write-back cache disk, use the PowerShell parameter New-ProvScheme CustomProperties. The custom properties are:

• UseTempDiskForWBC. This property indicates whether you are accepting to use the Azure temporary storage to store the write-back cache file. This must be configured to true when running New-ProvScheme if you want to use the temporary disk as write-back cache disk. If this property is not specified, the parameter is set to False by default.

For example, using the CustomProperties parameter to set UseTempDiskForWBC to true:

    -CustomProperties '<CustomProperties xmlns=" http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"> `
    <Property xsi:type="StringProperty" Name="PersistWBC" Value="false"/> `
    <Property xsi:type="StringProperty" Name="PersistOsDisk" Value="false"/> `
    <Property xsi:type="StringProperty" Name="PersistVm" Value="false"/> `
    <Property xsi:type="StringProperty" Name="StorageAccountType" Value="Premium_LRS"/> `
    <Property xsi:type="StringProperty" Name="WBCDiskStorageType" Value="Premium_LRS"/> `
    <Property xsi:type="StringProperty" Name="LicenseType" Value="Windows_Client"/> `
    <Property xsi:type="StringProperty" Name="UseTempDiskForWBC" Value="true"/> `
    </CustomProperties>'
<!--NeedCopy-->