"The Specified Key, Name, or Identifier Already Exists" after failed P2V

[Named_Jason]

Hi - we recently used Converter to migrate a system, but it failed initially due to the well documented com error mentioned here (http://www.vmware.com/community/thread.jspa?messageID=565719򊇗).

It now appears that, when converter failed, it did not successfully clean up after itself, having left references for the attempted VM name lingering in the VirtualCenter database (we assume). When we tried further conversions of the system, it failed with the above message "The Specified Key, Name, or Identifier Already Exists". Importing the machine under a different name was successful, but we would like to get it back to the original name (including the associated files for the VM).

Does anyone know of any way to make VirtualCenter display all references to Virtual Machines so that we could hopefully clean it out a bit (I think we need something of similar detail to using the /etc/vmware/esx.conf file for networking issues)?

[edinkozo]

Hi,

We received the same error when we are moving VM's with converter between ESX hosts (in that moment we haven't installed Virtual Center).

Our solution was renaming VM and once the migration is completed, we rename it back to their original name.

[pdpelsem]

Try running "service mgmt-vmware restart" on the target host after the failed p2v.

This solved a similar problem for me.

[eyezlee]

^^T his worked to fix my "The specified key, name, or identifier already exists" issue as well.

[bwilliamsdc]

Me too! Thanks much.

[mistatofa]

Thanks pdpelsem, fixed my issue too...

[mpverr]

VMware engineering suggests the following:

service mgmt-vmware restart

service vmware-vpxa restart

service vmware-vmkauthd restart

[BrianGem]

Some potential caveats when resolving "The specified key, name, or identifier already exists":

When I issued the service console command "service mgmt-vmware restart", several - but not all - of the virtual machines that were running on this host restarted.

After issuing the remaining service restart commands, I browsed the target datastore and noticed that the virtual machine configuration files (vmx, vmdk, etc.) had not been cleaned up after the failed migration (clone). I deleted the files and the folder containing the remnants of the failed clone. I was then able to clone the virtual machine successfully.

[stvkpln]

When I issued the service console command "service

mgmt-vmware restart", several - but not all - of the

virtual machines that were running on this host

restarted.

That was actually addressed in patch ESX-7557441: http://www.vmware.com/support/vi3/doc/esx-7557441-patch.html

[benny_hauk]

I'll add that just running 'service mgmt-vmware restart' on the SOURCE ESX host didn't do the trick - I still got the errors. Either doing one of 2 things finally got it working:

1) Doing what 'mpverr' suggests to actually run all 3 of the restarts

2) Making DRS completely manual (had it previously set to Partially manual). My thinking here was that I really wasn't sure what host VC was trying to add the new VM to (I was just trying to do a simple clone). I thought maybe another of my hosts was hosed (needed the 'service mgmt-vmware restart' also) so by setting it to manual I could guarrantee which host was being chosen as the DESTINATION host (I chose the one that was the SOURCE host and already had all those restarts). One alternative to this might be just to run 'service mgmt-vmware restart' on every host once you observe this bad behavior (restarting the VC service couldn't hurt either).

It would be greatly appreciated if future versions of VC wouldn't get confused and out-of-sync so easily (or if they could recover on their own better). The 2 times this has happened in the last 2 weeks have cost me more time than it would have to manually build these from scratch in the physical world.

[Kahonu]

The trio of commands fixed me!!

Mahalo,

Bill