Background :

Customers using XenDesktop Machine Creation Service (MCS) with VMWare, Xenserver or Hyper-v as hypervisor may want to relocate the desktops to another datastore for various reasons such as datastore running out of space or datastore performance. This article tells why Citrix does not support the datastore migration of VMs.

Reason  :

During the MCS catalog creation  :
MCS creates a Provisioning scheme which is associated to the HypervisorconectionID and storage ID, the storages which are defined under the hosting unit in the hosting tab on Studio console has those catalog IDs mapped, also all these information gets stored in the database during the creation of the catalog.
So if we go ahead and migrate those VMs and put them on a new storage, first of all DDC do not identify those VMs as our DB has those VMs mapped to other storage IDs and Provisioning IDs.
Even if we create a new host connection, we will not be able to map the existing Provisioning scheme with the new Hypervisor Connection due to limitation of Xendesktop Powershell SDKs.
1. When we create a MCS catalog HypervisorconnectionID and HostingUnitID gets mapped to the MCS catalog or Proviosning Scheme. Examples :

This is our Hypervisor connection which we created using studio under hosting tab :


 
Can retrieve the same information using powershell using the following commands :
PS C:\Users\administrator.ANUJ>asnp Citrix*
PS C:\Users\administrator.ANUJ> cd xdhyp:\
PS XDHyp:\> cd .\connections
PS XDHyp:\Connections> ls


 
Same goes to hostingunit :



Using powershell :

Run the following commands :
PS C:\Users\administrator.ANUJ>asnp Citrix*
PS C:\Users\administrator.ANUJ> cd xdhyp:\
PS XDHyp:\> cd .\hostingunits
PS XDHyp:\Connections> ls


 

2. Now we have to consider the Hypervisorconnection ID and HostingunitID From our example :
HypervisorConnectionName    : XDHost
HypervisorConnectionUid     : 4fcfdde4-6799-43d8-a7c1-4aec168889ce
HostingUnitName        : XDresource
HostingUnitUid         : a567b103-d54e-4dc8-9455-a04171c35d68

A. Run Get-ProvScheme to get an output of MCS created catalogs  and match the hosting unit name and hostingunit ID :  



b. Prov scheme or MCS catalog created with that Hosting resource should show the same ID.

3. One more alternate to check the same thing using VMs identity :  

PS XDHyp:\HostingUnits> Get-ProvVM -VMName "PVD2"(PVD2 is the machine name)
 

 
Take the output and compare with above IDs.
If the IDs matches, we will get to know the machines are associated to these storages, and there is no way to change these IDs using commands or GUI.
 
Note : Modifying the DB tables using DB queries are not supported.
 
Work Around currently available:

1. If it is a case of MCS Random catalog, we strictly recommend to create a new catalog with the available master image.
2. If it is a MCS Dedicated catalog , we can remove the machines from the catalog (via Studio, this operation will delete the machine's entry from the XenDesktop database), leave them in hypervisor and their machine accounts on active directory, we can now use the same machine to create a new catalog (non MCS/PVS) and import those machine in this catalog. (You can also add these machines to an existing non MCS/PVS catalog).
3. If it is a case of MCS with PVD machines, we can go through backup and restore process as per http://docs.citrix.com/en-us/xenapp-and-xendesktop/7/cds-manage-wrapper-rho/cds-about-personal-vdisks/cds-manage-personal-vdisks.html