Create machine catalogs 编辑

Collections of physical or virtual machines are managed as a single entity called a machine catalog. 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.

Studio guides you to create the first machine catalog after you create the site. After you create the first catalog, Studio guides you to create the first Delivery Group. Later, you can change the catalog you created, and create more catalogs.

Tip:

If you upgrade an existing deployment which enables the Machine Creation Services (MCS) storage optimization feature, referred to as MCS I/O, no additional configuration is required. The VDA and the Delivery Controller upgrade handle the MCS I/O upgrade.

Overview

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

Consider:

• MCS supports a single system disk from the virtual machine image. It ignores the rest of the data disks attached to that image.
• If you use Citrix Provisioning to create machines, see the Citrix Provisioning documentation for instructions.
• If you use MCS to provision VMs, you provide a master image (or snapshot of an image) 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 master image. This process includes installing a Virtual Delivery Agent (VDA) on the image. Then you create the machine catalog in Studio. You select that image (or snapshot), specify the number of VMs to create in the catalog, and configure additional information.
• If your machines are already available, you must still create one or more machine catalogs for those machines.
• If you are creating a catalog using the PowerShell SDK directly, you can specify a hypervisor template (VMTemplates), rather than an image or a snapshot.

When using MCS or Citrix Provisioning to create the first catalog, you use the host connection that you configured when you created the site. Later (after you create your first catalog and Delivery Group), you can change information about that connection or create more connections.

After you complete the catalog creation wizard, tests run automatically to ensure that it is configured correctly. When the tests complete, you can view a test report. Run the tests at any time from Studio.

Note:

MCS does not support Windows 10 IoT Core and Windows 10 IoT Enterprise. Refer to the Microsoft site for more information.

For technical details about the Citrix Provisioning tools, see Citrix Virtual Apps and Desktops Image Management.

RDS license check

Citrix Studio currently does not perform the check for valid Microsoft RDS licenses while creating a machine catalog that contains Windows multi-session OS machines. To view the status of the Microsoft RDS license for a Windows multi-session OS machine, go to Citrix Director. View the status of the Microsoft RDS license in the Machine Details panel in the Machine Details and the User Details page. For more information, see Microsoft RDS license health.

VDA registration

A VDA must be registered with a Delivery Controller (for on-premises deployments) or Cloud Connector (for Citrix Cloud deployments) 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 an administrator can troubleshoot. Studio provides troubleshooting information in the catalog creation wizard, and after you add machines from 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 might not be obtained about a machine (perhaps because it had never registered), add the machine anyway.

For more information, see:

• CTX136668 for VDA registration troubleshooting guidance
• VDA versions and functional levels
• VDA registration methods

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 a master 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 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 via the delivery controller.

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:

  • Personal vDisk provides end users with the ability to install applications without admin intervention on a separate disk attached to the VM.
  • AppDisk provides end users with the ability to attach the application-only disks to VMs primarily for multi-session OS Catalogs.
  • 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 above.

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

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

• Hypervisor overhead

  Different hypervisors utilize 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 with a 20 GB for the virtual disk, 16 GB for the virtual machine swap file (the size of an allocated memory), and 100 MB for log files, or 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. Therefore, a catalog that employs PvD or AppDisks needs more space than a simple pooled random catalog.
  • Updating the catalog allows 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

With the Machine Creation Services (MCS) storage optimization feature, referred to 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.
• Diagnostic improvements are achieved 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 in Citrix Studio 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. Except for Microsoft Azure environments, the pagefile is redirected to this formatted volume, MCSWCDisk. As a result, this disk size considers the total amount of disk space, including the delta between the disk size and the generated workload plus the pagefile size, typically associated with VM RAM size. Microsoft Azure pagefile is pre-configured to use a local temporary disk and is not redirected to MCSWCDisk by MCS storage optimization I/O functionality.

Enabling MCS storage optimization updates

To enable MCS I/O storage optimization functionality, 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.

When enabling the MCS storage optimization update, consider the following:

• When creating a machine catalog, the administrator can configure the RAM and disk size.

  

• When updating an existing machine catalog to a new VM snapshot containing a VDA with Citrix Virtual Apps and Desktops version 1903, it continues to use the existing catalog’s MCS I/O setting for RAM and disk size. The existing raw disk is formatted.

Important:

MCS storage optimization changed with Citrix Virtual Apps and Desktops version 1912 LTSR. This release supports file-based write cache technology, providing better performance and stability. The new functionality provided by MCS I/O could require a higher write cache storage requirement compared to previous Citrix Virtual Apps and Desktops releases. Citrix recommends that you reevaluate the disk size to ensure that it has sufficient disk space for the allocated workflow and additional pagefile size. The pagefile size is typically related to the amount of system RAM. If the existing catalog disk size is insufficient, create a new machine catalog and allocate a larger write cache disk.

About Microsoft Azure environments

By default, the MCS I/O write cache disk is provisioned during initial VM boot and is deleted after shutting down the VM. This is the most cost effective setting, however, the VM boot time is longer because it involves formatting the write cache disk and an extra reboot. For environments containing workloads with sensitive boot times, Citrix recommends using PowerShell to create a VM with persisted MCS I/O cache disk. The persisted cache disk is not deleted during the power cycle event, however, the cost of Azure storage account charges should be considered.

Using PowerShell to create an Azure catalog with persistent write-back cache disk

To configure an Azure catalog with persistent write-back cache disk, use the PowerShell parameter New-ProvScheme CustomProperties. This parameter supports an extra property, PersistWBC, used to determine how the write-back cache disk persists for Azure Resource Manager hosted MCS provisioned machines. The PersistWBC property is only used when the UseWriteBackCache parameter is specified, and when the WriteBackCacheDiskSize parameter is set to indicate that a disk is created.

Tip:

Because Azure presents numerous properties specific to provisioning, the CustomProperties field is used for many settings.

Examples of properties found in the CustomProperties parameter before supporting PersistWBC include:

<CustomProperties xmlns="http://schemas.citrix.com/2014/xd/machinecreation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<Property xsi:type="StringProperty" Name="UseManagedDisks" Value="true" />
<Property xsi:type="StringProperty" Name="StorageAccountType" Value="Premium_LRS" />
<Property xsi:type="StringProperty" Name="ResourceGroups" Value="benvaldev5RG3" />
</CustomProperties>
<!--NeedCopy-->