Product Documentation

Manage Personal vDisks

Apr 15, 2015

Storage for hosts with Personal vDisks

Note: You can upgrade this feature using Personal vDisk 7.x. This release contains new features and bug fixes, and is available as a download.

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.

Add Personal vDisks to existing hosts

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

  1. In Studio, click Configuration > Hosting and select a host.
  2. Click Add personal vDisk storage and specify the storage location.

Run the inventory when updating master images

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.

  1. Update the master image by installing any applications or operating system updates, and performing any system configuration on the machine. Other information on this step is provided in Prepare a master image.

    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.

  2. Shut down the machine. For Windows 7 machines, click Cancel when Citrix Personal vDisk blocks the shutdown.
  3. In the Citrix Personal vDisk dialog box, click Update Inventory. This step may take several minutes to complete.
    Important: If you interrupt the following shutdown (even to make a minor update to the image), the Personal vDisk's inventory no longer matches the master image. This causes the Personal vDisk feature to stop working. If you interrupt the shutdown, you must restart the machine, shut it down, and when prompted click Update Inventory again.
  4. When the inventory operation shuts down the machine, take a snapshot of the master image.

Adjust the space available for applications

You can manually adjust the automatic resizing algorithm that determines the size of the VHD relative to the P: drive. Typically, there is no need to make this adjustment because XenDesktop manages the split dynamically on its own. But if, for example, you know users will install a number of applications that are too big to fit on the VHD even after it is resized by the algorithm, you could increase the initial size of the application space to accommodate the user-installed applications. You adjust the space by editing the initial size of the VHD in the registry.

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.

Caution: Editing the registry incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.
  1. On the master image or desktop, locate the registry keys located in HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\personal vDisk\Config. You use several of these keys in the rest of this procedure.
  2. Set MinimumVHDSizeMB to the desired new initial size of the VHD (in megabytes). The new size must be greater than the existing size but less than the size of the physical disk minus PvDReservedSpaceMB.
  3. Ensure that PercentOfPvDForApps is set to 50. This sets the default allocation of space on the personal vDisk to 50%. If any other value is used, the dynamic resizing algorithm is disabled.
  4. Enable the algorithm by setting EnableDynamicResizeOfAppContainer to 1.
  5. If you are using a profile management solution (such as Citrix Profile management), check that EnableUserProfileRedirection is set to 0. This value ensures that all of the space on P: is allocated to applications.
If you are carrying out this operation on a virtual desktop rather than a machine catalog, resizing takes place when the desktop is restarted.

Disable automatic resizing

Caution: Editing the registry incorrectly can cause serious problems that may require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.
  1. On the master image or desktop, set EnableDynamicResizeOfAppContainer to 0. This registry key is located in HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\personal vDisk\Config.

Antivirus products

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.

Change the assignment of Personal vDisks

Important: In Provisioning Services, you can change the desktop that a Personal vDisk is assigned to in a machine catalog. When you do this, you must first put the desktop into maintenance mode in Studio, make the reassignment in Provisioning Services, and then wait for the desktop to re-register with the Delivery Controller before taking it out of maintenance mode. For instructions on reassigning desktops in machine catalogs, see the Provisioning Services documentation.

Back up and restore Personal vDisks

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:

  • migration-backup.ps1 captures the mapping between each user and their Personal vDisk in a machine catalog and stores this information in an .xml file.
  • migration-restore.ps1 uses the .xml file to re-create a user's desktop in a machine catalog.
Important: Before backing up and restoring, note the following:
  • The scripts work with the hypervisor API so the hypervisor’s PowerShell snap-in must be installed on the Delivery Controller where the scripts are executed
  • Run the scripts from a location that has access to the Delivery Controller where the machine catalog was created
  • The scripts are supported on the following hypervisor platforms: Citrix XenServer, Microsoft Hyper-V, and VMware ESX

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:

  • Perform a backup when a change is made to a machine catalog
  • You can take a backup while the machines in the machine catalog are active.

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

Important: Before restoring, note the following:
  • You can only restore a machine catalog that shares the same master image as that of the backed-up machine catalog
  • You must create a new master image by updating the inventory of the master image that the backed-up machine catalog was created from.

Use migration-restore.ps1 to restore any machine catalog containing Personal vDisks. The script takes the following inputs:

  • The .xml file created during the backup process.
  • The name of the machine catalog to restore.
  • The name of the location where the unattached Personal vDisks are stored. This is listed in the .xml file.
  • Hypervisor connection information.

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.

Scenarios

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.

  1. Run migration-backup.ps1 to capture the user-to-Personal-vDisk mapping in the .xml file.
  2. Using a backup solution, move or capture the Personal vDisks from the original machine catalog on to a disk:
    • VMware ESX or Microsoft Hyper-V: Personal vDisks are located on the storage specified by the Delivery Controller, in a folder containing the name of the machine to which the vDisk is attached.
    • Citrix XenServer: Personal vDisks are located in the root of the storage specified by the Delivery Controller. The name of each vDisk is a GUID.
  3. Restore the Personal vDisks from the original machine catalog using a storage backup solution:
    • ESX or Hyper-V: Locate the vDisks in a new folder of the new storage resource. Alternatively, leave the vDisks in the original path on the new storage resource.
    • XenServer: Locate the vDisks in the root of the new storage resource.
  4. Create a Provisioning Services vDisk or a Machine Creation Services snapshot from the master image that you used to create the failed machine catalog.
  5. Run Update Inventory from the Start menu on the vDisk or snapshot.
  6. Re-create the machine catalog in Studio using a different naming convention as the failed (original) machine catalog. This generates a catalog of new machines, each with a new Personal vDisk, that the XenDesktop database recognizes.
  7. Verify that the re-created machine catalog is assigned to the correct Delivery Group.
  8. Verify that the Desktop Group is in maintenance mode and the machines in it are shut down.
  9. Edit the .xml file generated by the backup script:

    • ESX or Hyper-V: If you restored the vDisks to a new folder on the new storage resource in Step 3, for every PVD section in the file, replace the folder name in DiskName with the location of the restored vDisks. If you restored the vDisks to the original path on the new storage, skip this step.
    • XenServer: Skip this step.
  10. On the Delivery Controller, run migration-restore.ps1, specifying the name of the .xml file and the location where the backed-up vDisks are stored.

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.

  1. Run migration-backup.ps1 to capture the user-to-Personal-vDisk mapping.
  2. Using a backup solution, move or capture the Personal vDisks from the original machine catalog on to a disk:
    • ESX or Hyper-V: Personal vDisks are located on the storage specified by the Delivery Controller, in a folder containing the name of the machine to which the vDisk is attached.
    • XenServer: Personal vDisks are located in the root of the storage specified by the Delivery Controller. The name of each vDisk is a GUID.
  3. Restore the Personal vDisks from the original machine catalog using a storage backup solution:
    • ESX or Hyper-V: Locate the vDisks in a new folder of the new storage resource.
    • XenServer: Locate the vDisks in the root of the new storage resource.
  4. Create a Provisioning Services vDisk or a Machine Creation Services snapshot from the master image that you used to create the failed machine catalog.
  5. Run Update Inventory from the Start menu on the vDisk or snapshot.
  6. Re-create the machine catalog in Studio using the same naming convention as the failed machine catalog. This generates a catalog of new machines, each with a new Personal vDisk, that the XenDesktop database recognizes.
  7. Verify that the re-created machine catalog is assigned to the correct Delivery Group.
  8. Verify that the Desktop Group is in maintenance mode and the machines in it are shut down.
  9. Edit the .xml file generated by the backup script:

    • ESX or Hyper-V: For every PVD section in the file, replace the folder name in DiskName with the location of the restored vDisks.
    • XenServer: Skip this step.
  10. Run the migration-restore.ps1 script on the Delivery Controller with the modified .xml file as an input. The script attaches the vDisks without moving them.
  11. Verify the users' data has been successfully restored.

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.

  1. Run migration-backup.ps1 to capture the user-to-Personal-vDisk mapping in the .xml file.
  2. The .xml file has a PVD section for each user in the machine catalog. For any users whose Personal vDisks do not need restoring, remove the users and their associated sections from the file.
  3. Restore the Personal vDisks from the original machine catalog using a backup solution, as described in the one of the other scenarios:
    • To use new machine names, follow Scenario 1.
    • To preserve machine names, follow Scenario 2.
  4. Ensure there are enough unassigned machines in the catalog. Add machines if necessary. You need one new machine for each user whose vDisk you want to restore.
  5. Verify that the Desktop Group is in maintenance mode and the machines in it are shut down.
  6. On the Delivery Controller, run migration-restore.ps1 with the modified .xml file as an input.
  7. Verify the users' data has been successfully restored.