- Manage Personal vDisks
When you create a host, you define storage locations for disks that are used by virtual machines. You can separate the Personal vDisks, which store the user profiles and user-installed applications, from the disks used for the machines’ operating system. Each virtual machine must have access to a storage location for both disks. If you use local storage for both, they must be accessible from the same hypervisor. To ensure this requirement is met, Studio offers you only compatible storage locations when you create the host.
Back up Personal vDisks regularly using any preferred method. The vDisks are standard volumes in a hypervisor's storage tier, so you can back them up just like any other volume.
You add Personal vDisks to new hosts when you configure a new XenDesktop site. You can also add Personal vDisks and storage for them to existing hosts (but not machine catalogs).
You enable the Personal vDisk feature for use with a master image when you install the Virtual Delivery Agent. During the installation procedure and after any update to the image after installation, it is important that the disk's inventory is refreshed and a new snapshot is created. This procedure describes the required steps.
Because administrators, not users, manage master images, if you install an application that places binary files in the administrator's user profile, the application is not available to users of shared virtual desktops (including those based on pooled machine catalogs and pooled with Personal vDisk machine catalogs). Users must install such applications themselves.
It is best practice to take a snapshot of the image after each step in this procedure.
For master images based on Windows XP that you plan to deploy with Personal vDisks, check that no dialog boxes are open (for example, messages confirming software installations or prompts to use unsigned drivers). Open dialog boxes on master images in this environment prevent the Virtual Delivery Agent from registering with the Delivery Controller. You can prevent prompts for unsigned drivers using the Control Panel. For example, on Windows XP click System > Hardware > Driver Signing, and select the option to ignore warnings.
Preferably, you make this adjustment on a machine catalog's master image (that is, before the desktops in the machine catalog are released to users). Alternatively, you can adjust the size of the VHD on a virtual desktop, when a user finds that they do not have the space to install an application, but you must repeat this operation individually on each affected virtual desktop; you cannot adjust the size in a machine catalog that is already in use.
If antivirus products are installed on your desktops, ensure the VHD is big enough to store antivirus definition files, which are typically large.
The presence of antivirus products can affect how long it takes to run the inventory or perform an update. Performance can improve if you add CtxPvD.exe and CtxPvDSvc.exe to the exclusion list of your antivirus product. These files are located in C:\Program Files\Citrix\personal vDisk\bin.
Two PowerShell scripts supplied on the XenDesktop media allow you to back up and restore Personal vDisks. The scripts are located in the Support\Tools\Scripts folder:
Back up a machine catalog
Use migration-backup.ps1 to back up any machine catalog containing Personal vDisks. The script asks for the name of the machine catalog and connection information for the hypervisor. It then iterates through all of the user-assigned machines in the machine catalog and, for each machine, stores the mapping between the Personal vDisk storage and the assigned user. This information is located in an .xml file. Note that:
The structure of the .xml file is as follows:
<PVDMigration> <hypervisor> <type></type> </hypervisor> <PVD> <DiskId></DiskId> <DiskName></DiskName> <SRName></SRName> <SRID></SRID> <UserName></UserName> <UserSid></UserSid> <State></State> </PVD> </PVDMigration>
PvDMigration.hypervisor.Type supports VMware ESX, Citrix XenServer, and Microsoft Hyper-V.
PvDMigration.PVD stores information on where the Personal vDisk is stored and the user associated with it.
PvDMigration.PVD.DiskId is the unique identifier of the vDisk on the hypervisor on which the backup was taken.
PvDMigration.PVD.DiskName is the name of the .vhd or .vmdk file.
PvDMigration.PVD.SRName is the name of the storage provider when the backup was taken.
PvDMigration.PVD.SRID is the unique identifier of the storage provider on the hypervisor on which the backup was taken.
PvDMigration.PVD.UserName is the name of the user associated with this vDisk.
PvDMigration.PVD.UserSid is the SID of the user associated with this vDisk.
PvDMigration.PVD.State indicates the state of this vDisk. This can be either backed up or processed. It is backed up after the initial backup. The state changes to processed after the .xml file is used for restoring from the backup.
Restore a machine catalog
Use migration-restore.ps1 to restore any machine catalog containing Personal vDisks. The script takes the following inputs:
migration-restore.ps1 finds any unassigned machines in the machine catalog and assigns users to them. It also attaches users' Personal vDisks to the machines.
Depending on the number of users, you restore their vDisks differently. The rest of this section provides some example scenarios.
Scenario 1 - Restore a machine catalog and its Personal vDisks using new machine names
In this scenario, an entire machine catalog and the Personal vDisks attached to the machines in it are restored. The machines are given new names. This scenario may be necessary when your hypervisor or a storage host has failed, or when you migrate users to a new infrastructure.
Edit the .xml file generated by the backup script:
Scenario 2 - Restore a machine catalog and its Personal vDisks reusing existing machine names
In this scenario, an entire machine catalog and the Personal vDisks attached to the machines in it are restored. Existing (failed) machine names are reused. This scenario may be necessary when your hypervisor or a storage host has failed.
Edit the .xml file generated by the backup script:
Scenario 3 - Restore a subset of Personal vDisks in a machine catalog
In this scenario, some, but not all, of the Personal vDisks in a machine catalog have failed and are restored. The virtual machines in the catalog have not failed.