Configuring replication on a virtual machine with multiple disks on different datastores fails with the error: Unable to create placeholder virtual disk

Products

• VMware Live Recovery
• VMware vSphere ESXi

Issue/Introduction

• When you configure replication for a virtual machine which has two or more virtual disks (vmdk) on two or more datastores using vSphere Replication or Site Recovery Manager (SRM), the operation fails with the error:
  
  inherited from com.vmware.vim.binding.hms.fault.HmsMethodFault: Unable to create placeholder virtual disk.
  
  
• The replication group is left in an erroneous state.

Environment

VMware vCenter Site Recovery Manager 5.1.x
VMware vCenter Site Recovery Manager 4.1.x
VMware vCenter Site Recovery Manager 5.0.x
VMware vSphere Replication 5.1.x

Resolution

Cause

By default, when virtual machine disks are created in different datastores, they are assigned the same name (testvm.vmdk).

This is an example environment to illustrate the issue:

• A virtual machine named testvm that has three virtual disks on three different datastores
• A primary replication site named prod1
• A secondary replication site named prod2

You want to replicate from prod1 (datastore_a, datastore_b, datastore_c) to prod2 (datastore_d).

The file structure at prod1 looks like:

• Hard disk 1: /vmfs/volumes/datastore_a/testvm/testvm.vmdk
• Hard disk 2: /vmfs/volumes/datastore_b/testvm/testvm.vmdk
• Hard disk 3: /vmfs/volumes/datastore_c/testvm/testvm.vmdk

The error occurs because the three virtual disks named testvm.vmdk cannot exist in the same datastore (datastore_d) on the secondary site. A unique name for all files is required by file system standards.

If you allow the replication task to proceed, the file structure at prod2 looks like:

• Hard disk 1: /vmfs/volumes/datastore_d/testvm/testvm.vmdk
• Hard disk 2: /vmfs/volumes/datastore_d/testvm/testvm.vmdk
• Hard disk 3: /vmfs/volumes/datastore_d/testvm/testvm.vmdk

By design, vSphere Replication does not rename disks to prevent possible collision. For more information, see Configuring Replication Fails for Virtual Machines with Two Disks on Different Datastores in the vSphere Replication 5.1 documentation.

Workaround

To work around this issue, configure each replicated virtual machine disk to use a different destination path on the secondary site.

Resolution

To allow replication of a virtual machine from a multiple datastore source configuration on the primary site to a single datastore destination on the secondary site, the files must have unique names so that the disks can co-exist in the same directory.

There are two methods available to give the files the required unique names:

Method 1

Give the disks unique names using Storage vMotion. This requires no virtual machine downtime.

1. Perform the required migrations on the primary site using Storage vMotion. For more information, see Migrate a Virtual Machine with Storage vMotion in the vSphere Client in the vSphere 5 Documentation Center.
   
   
2. Temporarily migrate all VMDK disks to a single datastore (datastore_e), which results in each disk being given a unique name.
   
   After the first migration is complete, the file structure at prod1 looks like:
   
   
   • Hard disk 1: /vmfs/volumes/datastore_e/testvm/testvm.vmdk
   • Hard disk 2: /vmfs/volumes/datastore_e/testvm/testvm_1.vmdk
   • Hard disk 3: /vmfs/volumes/datastore_e/testvm/testvm_2.vmdk
   
   
3. Migrate the disks back to their original datastores.
   
   After the second migration is complete, the file structure at prod1 looks like:
   
   
   • Hard disk 1: /vmfs/volumes/datastore_a/testvm/testvm.vmdk
   • Hard disk 2: /vmfs/volumes/datastore_b/testvm/testvm_1.vmdk
   • Hard disk 3: /vmfs/volumes/datastore_c/testvm/testvm_2.vmdk

Method 2

Give the disks unique names by renaming them using the vmkfstools -E command. This requires virtual machine downtime.

• Rename each VMDK disk with a unique name using the vmkfstools -E command. For more information, see Renaming a virtual machine disk (VMDK) via the vSphere Management Assistant (vMA) or vSphere CLI (vCLI) (1002491).