Duplicate VM get's detected but Original VM get's deleted when Content-Library Template is used

We had a use-case where user accidentally passed VM name which was already provisioned and existing on vCenter through vRA 8.x

The moment this was done, request was anyways expected to fail detecting that there is a VM with the same name already present on the endpoint

2021-04-05T00:03:29.934Z ERROR provisioning [host='provisioning-service-app-67b88d497d-w7cvq' thread='vsphere-io-72' user='' org='' trace='' parent='' span=''] c.v.p.c.m.a.v.VSphereAdapterInstanceService.log:453 - [8282/provisioning/vsphere/instance-adapter] Error in createInstanceAsync [com.vmware.photon.controller.model.adapters.vsphere.vapi.RpcException: Cannot deploy library item 1f19595c-1770-4288-b76c-d44b0766d232 ( com.vmware.vdcs.util.duplicate_name  An object of type "ManagedObjectReference: type = VirtualMachine, value = vm-45, serverGuid = ae737187-1a20-4c5c-a1cd-9d7b3f7e1d8c" named "vcdrphoton" already exists.)
at com.vmware.photon.controller.model.adapters.vsphere.vapi.VapiClient.throwIfError(VapiClient.java:261)
at com.vmware.photon.controller.model.adapters.vsphere.vapi.LibraryClient.deployOvfLibItem(LibraryClient.java:453)
at com.vmware.photon.controller.model.adapters.vsphere.InstanceClient.createInstanceFromLibraryItem(InstanceClient.java:4309)
at com.vmware.photon.controller.model.adapters.vsphere.VSphereAdapterInstanceService.createInstanceAsync(VSphereAdapterInstanceService.java:498)
at com.vmware.photon.controller.model.adapters.vsphere.VSphereAdapterInstanceService.lambda$handleCreateInstanceAsync$11(VSphereAdapterInstanceService.java:351)
at java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
at java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
]

Example Blueprint

formatVersion: 1
inputs: {}
resources:
  VirtualMachine:
    type: Cloud.vSphere.Machine
    properties:
      name: testone
      image: photonfour
      flavor: small
      networks:
        - network: '${resource.Network.id}'
          assignment: static
  Network:
    type: Cloud.vSphere.Network
    properties:
      networkType: existing

If this issue occurs when using a normal vSphere template , there is no impact. But if your using a content library based template and then there is a risk that the original virtual machine with the same name get's deleted

For vCenter 7.x , please upgrade your vRealize Automation version to 8.3 P1

For vCenter 6.x , fix would be part of vRealize Automation 8.4 Patch 1

All we need to ensure is that do not pass an existing virtual machine name when using Content Library templates