“Save Location of VMDK” Bug in Virtual Center

So while doing a Proof of Concept test on a replication product for P2V, V2V and V2P scenarios a very interesting “bug” was encountered in Virtual Center that i’ve never encountered before.  We have to add .vmdk files that belong to VM “containers” to a “Master” VM.  So if you are protecting a SQL Server, you’ll have this “Master” VM’s .vmdk and the SQL VMs .vmdk attached to this VM.

The bug is this;

If you go and add another .vmdk to a VM, AFTER already choosing “attach an already existing vmdk” for a previously added vmdk, that new .vmdk will be created in the “already existing vmdk”s folder.

Since i’ve been working crazy hours, i’ll take a second to explain better.

So you have 2 VMs, they are named, “Master”, & “SQL”.  Each one is on a separate datastore in its’ own similarly named folder, which is default.  Then you go and add a 2nd vmdk to “Master” but choose to attach the vmdk from “SQL”.  Now you create another vmdk on the “Master”, however this is a new VMDK.  If you specify the location “store with the virtual machine”, it does not save the vmdk with the “Master” vmx, which is in the “Master” folder, instead it creates the new vmdk in the “SQL” folder.  This is quite interesting….

After digging around through the logs and doing some very quick testing, i found, what i believe, is the answer.  It seems that the “store with the virtual machine” is not actually returning with the location of the .vmx file, but actually returning with the location of last disk entry of the .vmx, so in this case “SQL”.

I would assume this is a simple fix by vmware, however since i have not encountered this before i’m wondering if i have just been lucky or if this is a new issue.

Leave a Reply

Your email address will not be published. Required fields are marked *