Copying VMs requires hand-editing VMX file

[probichaux]

Apologies if this is a well-known issue.

I created a base x86 VM that I wanted to clone. A quick cmd+D in the Finder gave me a copy of the folder; I renamed all the files in the folder and used the "Browse for VM" command to open it. Once I did this, Fusion prompted me to find each of the associated files-- except that it kept prompting me over and over and over and ... for the vmdk file. However, opening the vmx file with a text editor and pointing it to the correct vmdk file solved the problem and allowed me to generate a new UUID and boot the machine.

[rcardona2k]

>quick cmd+D in the Finder gave me a copy of the folder; I renamed all the files in the folder and used the "Browse for VM" command to open it.

The renaming of all files is what's causing your problem. The VMX file has reference to the VMDK by name. You should only really need to raname the VMX file and change the displayName field.

Unless you really want to change the VMDK filename, you can find the old name in the VMX and update it to the new name.

[probichaux]

Sorry I wasn't more clear. I have to set up a group of test images, so I built a pair of base VMs: one x86, one x64. Each has all the current patches and the base software I need to test with. I then made copies of these base VMs to join them to the appropriate domains and set up the test harnesses. I'm not using VMTN machines (which I think the original reply mentioned), and I do want to have separate vmdk files for each VM.

Having said that, the vmx files appear to have relative path names, although the mounted ISO image for the CD drive is an absolute path. I don't mind having to edit the files; I just wanted to get it on record that you'll be prompted endlessly to locate the vmdk file \*unless* you edit the vmx by hand. The nvram and other files don't seem to have this issue.

Edited to clear up my requirement for separate vmdk files

[rcardona2k]

Yes, originally I was thinking ahead and answering your followup question until I read "I renamed all the files" and then I thought aha! that's the basic problem.

The reason VMTN VMs are portable without (mostly) any prompting is they have no relative and absolute paths for any devices. This is exactly the best way to make VMs portable for cloning, migration, etc.

In your scenario, if you don't care about the cloned VMs having the same VMDK filename in each folder, then remove all the absolute and relative paths in both the VMX and VMDK files. Of course the files all need to be in that same folder and not above (..\..). Files can be in subdirectories so long as you keep the relative subdirectory names the same, e.g. config1/my-os.vmdk, config2/my-data.vmdk. But the simpler obviously the better.