"The operation could not be performed because the device spec is invalid" when performing a failover of a replication

Products

• VMware Cloud Director

Issue/Introduction

• When performing a failover of a replication in Cloud Director Availability (VCDA), the task fails with an error similar to:

The operation could not be performed because the device spec is invalid, Invalid operation for device 'x'.

• In the /opt/vmware/h4/cloud/log/cloud.log file on the destination Cloud Director Replication Management Appliance, there are entries similar to:

2024-05-03 13:42:58.727  WARN - [UI-9141d5d8-fc01-472a-b7a9-35a773185c63-r24862-qD-qkh] [task-poller-2] com.vmware.h4.cloud.job.VmFailoverJob    : Task to import the recovered VC VM into a new vCD vApp has failed.

 

com.vmware.vcloud.client.exception.VcloudException: (Major code = 500, minor code = INTERNAL_SERVER_ERROR) - [ UI-9141d5d8-fc01-472a-b7a9-35a773185c63-r24862-qD-qkh-44d3c651-40a7-49a8-a8eb-cb90fbd66b19 ] The operation could not be performed because the device spec is invalid. Invalid operation for device '1'.

vCenter Server task (moref: task-5430845) failed in vCenter Server '<vCenter name>' (########-####-####-####-###########).

 - Invalid operation for device '1'.

at com.vmware.vcloud.client.util.VcdTaskMonitor.lambda$pollTasksImpl$1(VcdTaskMonitor.java:92)

at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)

at com.vmware.vcloud.client.util.VcdTaskMonitor.pollTasksImpl(VcdTaskMonitor.java:70)

at com.vmware.vcloud.client.util.VcdTaskMonitor.pollTasks(VcdTaskMonitor.java:58)

at com.vmware.vcloud.client.util.VcdTaskMonitor.lambda$new$0(VcdTaskMonitor.java:52)

at com.vmware.h4.common.mdc.MDCRunnableWrapper.run(MDCRunnableWrapper.java:30)

at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)

at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)

at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305)

at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)

at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)

at java.base/java.lang.Thread.run(Thread.java:833)


• In /var/log/vpxa.log file on destination ESXi host, the task returned with error message "Disks with parents cannot be expanded".

  YYYY-MM-DD hh:mm:ss.xxxZ info vpxa[2104961] [Originator@6876 sub=Default opID=vcd-UI-92ab292d-b138-48d1-bef9-ce4549e09037-r3839-qJ-5bd78370-9e9a-430b-9515-6a35bfa2b67a;activity=urn:uuid:482cc5b7-11d5-4e1b-b907-dd2511b86246-40-01-5d] [VpxLRO] -- ERROR task-50397 -- vm-88 -- vim.VirtualMachine.reconfigure: vim.fault.InvalidDeviceOperation:
    --> Result:
    --> (vim.fault.InvalidDeviceOperation) {
    -->    faultCause = (vmodl.MethodFault) null,
    -->    faultMessage = (vmodl.LocalizableMessage) [
    -->       (vmodl.LocalizableMessage) {
    -->          key = "msg.hostd.configSpec.diskExtend.hasParent",
    -->          arg = <unset>,
    -->          message = "Disks with parents cannot be expanded."
    -->       }
    -->    ],
    -->    property = "virtualDeviceSpec.device",
    -->    deviceIndex = 0,
    -->    badOp = <unset>,
    -->    badFileOp = <unset>
    -->    msg = "Invalid operation for device 'X'."
    --> }
    --> Args:

Environment

• VMware Cloud Director Availability 4.x
• VMware Cloud Director 10.5.1

Cause

This issue occurs when a recovered VM's disk size is not a positive integer in megabytes, resulting in a reconfigure task that attempts to change the disk capacity while associating storage policies during the import into VMware Cloud Director (VCD).

e.g.

• When a vmdk's size is configured with 2.83 TB:
  2.83 TB * 1024 * 1024 = 2,967,470.08 MB --> it is not a positive integer in megabytes.
  
  
• When a vmdk's size is configured with 2830 GB:
  2830 GB * 1024 = 2,897,920 MB --> it is a positive integer in megabytes

Resolution

This is a known issue affecting VMware Cloud Director 10.5.1.

Currently, there is no resolution.

Workaround

There are two workarounds, and either one will work.

Workaround 1st: Modify target VM

1. Log into the destination vCenter Server where the VMs were recovered to.
2. In the Hosts and Clusters Inventory view, navigate to the Organization VDC resource pool.
3. Search for the recovered VM with the same name as the source VM.
4. Right-click on the VM and select the Edit Settings option.
5. For any hard disks with a decimal point value, increase the disk size to the next whole gigabyte value.
6. Navigate to the Cloud Director Availability Portal and re-attempt the failover.

Workaround 2nd: Modify source VM

1. Log into the source vCenter Server and find the source VM;
2. Right-click on the VM and select the Edit Settings option;
3. For any hard disks with a decimal point value, increase the disk size to the next whole gigabyte value;
4. Navigate to the Cloud Director Availability Portal and re-configure the replication. Before this operation, historic VM backup should be deleted.