Create machine catalogs 编辑

Important:

As of Citrix Virtual Apps and Desktops 7 2006, if your current deployment uses any of the following technologies or host types, you can upgrade your deployment to the current release. Do this only after removing items that use those technologies.

• Personal vDisks (PvDs)
• AppDisks
• Public cloud host types: Amazon Web Services (AWS), Citrix CloudPlatform, Microsoft Azure Classic, Microsoft Azure Resource Manager

For details, see Remove PVD, AppDisks, and unsupported hosts.

Introduction

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.

Citrix 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:

Upgrading an existing deployment enables the Machine Creation Services (MCS) storage optimization (MCS I/O) feature, no additional configuration is required. The Virtual Delivery Agent (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 the 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.
• Using a template to provision a catalog is considered an experimental feature. When using this method, virtual machine preparation might fail. As a result, the catalog cannot be published using the template.

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. This panel is located 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 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.

After you add existing machines using the wizard, 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, either remove that machine, or add the machine. For example, if a message indicates that information might not be obtained about a machine, 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:

  • 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 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 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

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.
• 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 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. 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

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.

  

• Updating an existing machine catalog to a new VM snapshot containing a VDA configured for version 1903 results in the following behavior: the new snapshot 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 1903. This release supports file-based write cache technology, providing better performance and stability. The new functionality provided by MCS I/O might 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 extra pagefile size. The pagefile size is typically related to the amount of system RAM. If the existing catalog disk size is insufficient, create a machine catalog and allocate a larger write cache disk.

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

To configure a 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 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.

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-->