VMware Cloud Community
Named_Jason
Contributor
Contributor

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

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)?

Reply
0 Kudos
10 Replies
edinkozo
Contributor
Contributor

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.

Reply
0 Kudos
pdpelsem
Enthusiast
Enthusiast

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

This solved a similar problem for me.

Reply
0 Kudos
eyezlee
Contributor
Contributor

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

Reply
0 Kudos
bwilliamsdc
Contributor
Contributor

Me too! Thanks much.

Reply
0 Kudos
mistatofa
Contributor
Contributor

Thanks pdpelsem, fixed my issue too...

Reply
0 Kudos
mpverr
Enthusiast
Enthusiast

VMware engineering suggests the following:

service mgmt-vmware restart

service vmware-vpxa restart

service vmware-vmkauthd restart

Reply
0 Kudos
BrianGem
Contributor
Contributor

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.

Reply
0 Kudos
stvkpln
Virtuoso
Virtuoso

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

-Steve
Reply
0 Kudos
benny_hauk
Enthusiast
Enthusiast

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.

Benny Hauk Systems Admin, VCP3/VCP4 LifeWay Chrstian Resources
Reply
0 Kudos
Kahonu
Enthusiast
Enthusiast

The trio of commands fixed me!!

Mahalo,

Bill

Reply
0 Kudos