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
Comments