This weekend I chose to decommission one of my old servers. This involved “evacuating” all of its VMs to a new server. Evacuating seems to be a quite unpleasant term, and sounds like some kind of painful clonic irrigation for ESX. Actually, what I mean is “cold migration”. I had two errors. The first said “Invalid configuration for device 1″ and the other said “The specified key, name, or identity already exists”. What was annoying about both errors is that the failure came at 99% of the progress bar, and caused the VM to remain on the source ESX host.
The first was caused by having a locally mounted ISO image, which ordinarily wouldn’t cause a problem at cold migration (unless in VMotion), but would at the point of powering on the VM once it had been moved because the local mounted image wouldn’t be on the destination ESX host. However, in this case the error didn’t manifest itself at power on, as the cold migrate failed at 99%. The cold migration did warn me about this connected ISO, but as I had the chance to ignore the warning (not an error) I did. Disconnecting and removing the configuration to the local image stopped this problem from occurring. Moral: It's worth resolving any errors or warnings immediately, rather than finding out they cause a problem later.
The second was more complicated. It was like I was trying to move a VM called DC1, to an ESX host that already had a VM called DC1, which it didn’t. There was no reference to the VM elsewhere in VirtualCenter and no files called DC1 on the destination VMFS volume. The work around, which I found on the forums after a google-wack to temporarily rename the VM before the cold migrate – cold migrate the VM – and then rename it back after the process was completed. I never got down to the bottom of why this happened, but I believe it was caused by some database integrity issue. Perhaps that object was still referenced in the database somewhere, had become orphaned, and hadn’t been purged yet in the standard knowledge consistency. Check process in SQL.