V2V not working correctly with snapshots

[jmmarton]

I have an existing Windows 2000 Server VM running under VMware Server. I'm trying to use VMware Converter 3.0 to import this VM into my new ESX environment. Initially I received the error "Unable to detect Guest Operating System" but I resolved that error using the following tip from blog.scottlowe.org:

"Edit the .vmx file to remove the “-NNNNNN” suffix that is automatically appended to the names of any VMDK files referenced in the .vmx file. Make sure the VMDK filenames referenced in the .vmx file are indeed unique (they should be)."

After doing that, the VM imported. However I saw that the state of the machine after the import was as it existed before I took the existing snapshot that exists for the VM. I took the snapshot before upgrading the app that runs in the VM, GroupWise Mobile Server, and I can see that the imported VM has the old version of GMS on it that existed prior to the snapshot.

The other thing I tried to do was manually copy the *.VMDK files over to the ESX server and using vmkfstools to convert it over to ESX format. I then created a new VM in ESX, and for the hard disk I pointed it to the existing file. Again I'm seeing what existed before the current snapshot was taken.

The other thing that's weird is that I created a single flat file, 33GB, and I preallocated all the space. In the directory where the VM exists I can see a subdirectory that contains gms.vmdk, the text file, and gms-flat.vmdk, the 33GB file. However in the directory of the VM itself is gms-000001.vmdk, and it's 3.5GB. This is what's being referenced in the VMX file, and this is what that tip from scottlowe.org was talking about I think. Is this the file that contains all the changes since the snapshot? Is this what's throwing off VMware Converter? Is there any way I can get this VM migrated to ESX, and have it migrated it its current state rather than a previous state?

[continuum]

"Edit the .vmx file to remove the “-NNNNNN” suffix that is automatically appended to the names of any VMDK files referenced in the .vmx file. Make sure the VMDK filenames referenced in the .vmx file are indeed unique (they should be)."

This is VERY,VERY BAD ADVICE

Please tell the writer of this nonsense to stop spreading such s@#?###

I do not know if you still can recover your current VM - next time you have to do something like this create a full clone before trying to migrate the VM - or remove all snapshots first.

Oh dear - I wish VMware-bloggers would stop to spread such uninformed - missguiding "tips"

Ulli

[jmmarton]

This is VERY,VERY BAD ADVICE

Please tell the writer of this nonsense to stop

spreading such s@#?###

Ok, I'll remember to not do this one again.

I do not know if you still can recover your current

VM - next time you have to do something like this

create a full clone before trying to migrate the VM -

or remove all snapshots first.

Well recovering was a snap--all the work I was doing was with a complete backup copy of the VM. So, to be safe, it sounds like I should take a new backup copy of this VM, copy that over to another VMware Server I have going, remove the snapshots, then from there try to do the conversion again. I'll give that a shot later on today and we'll see how she goes.