/opt/vmware/vcloud-director/logs/vcloud-container-debug.log entries similar to the following are seen during the failed copy/move task.DEBUG | Backend-activity-pool-408 | ComputeVmImpl | Setting VALRef of Compute VM ##########-####-####-####-########## to [vcId=##########-####-####-####-##########, moref=vm-###] | requestId=##########-####-####-####-##########,request=POST https://<cloud.example.com>/api/catalog/##########-####-####-####-##########/action/move,requestTime=1782116034143,remoteAddress=1<ipaddress>,userAgent=Mozilla/5.0 (X11; Linux x86_64; rv:140.0) Gecko/20100101 Fire...,accept=application/*+xml;version 40.0.0-alpha vcd=##########-####-####-####-##########,task=##########-####-####-####-##########activity=(com.vmware.vcloud.backendbase.management.system.TaskActivity,urn:uuid:##########-####-####-####-##########) activity=(com.vmware.vcloud.vdc.impl.CopyContentsActivity,urn:uuid:##########-####-####-####-##########)VMware Cloud Director 10.6.1.x
This issue occurs when a failed virtual machine copy task results in a duplicated Managed Object Reference (MoRef) ID assignment, causing both the source and destination VMs to share the same MoRef identifier in Cloud Director. As VMware Cloud Director expects a 1:1 relational mapping between vCenter Server managed objects and its own inventory database records, the presence of these duplicate entries can result in the source template VM being incorrectly removed from the vCenter level if an attempt is made to delete the destination template placeholder which was in the failed copy state.
This is a known issue affecting VMware Cloud Director. Currently, there is no resolution.
Subscribe to this knowledge article to get updates on this issue.