VMware Cloud Community
Ryguy01
Contributor
Contributor

Moving ESXi 3.5 VMDK to Esxi 4.0

I have an ESXi 3.5 standalone server and a ESXi 4.0 stand alone server. A drive went out on my ESXi 3.5 server but I was able to recover the VMDK files I needed and I would like to get them up and running on my 4.0 box. I added the first one to inventory - it is an Ubuntu 32-bit install, when i boot up the VM I get a "GRUB loading please wait..... Error 2" on the console of the VM. I am troubleshooting this issue and I am wondering if I need to convert this VM from 3.5 to 4.0 before adding it to inventory. The Error 2 message in Ubuntu leans toward a problem finding the drive.

Please help!! Thank you!!

Tags (4)
0 Kudos
10 Replies
weinstein5
Immortal
Immortal

Welcome to the Forums - There is no conversion necessary to move VMDK from 3.5 to 4 - did you also salvage the configuration file (.VMX)? Did you rebuild the VM and point to the existing vmdk?

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful

If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful
0 Kudos
Ryguy01
Contributor
Contributor

My process was to create a new custom VM on the 4.0 server and select the VMDK file. I tried selecting both a Version 4 machine and a Version 7 machine during the new VM creation wizard. I thought it was possible the VMDK was corrupt but from what I have read it would not have mounted and started up if this was the case.

Do you think it is possible the VMDK is corrupt even though it mounted? I am unfotunately a novice Ubuntu user so I am troubleshooting the GRUB error 2 under the assumption now that the VMDK is intact. What are you thoughts?

0 Kudos
Ryguy01
Contributor
Contributor

Sorry forgot to answer other portion - Yes I do have the original VMX file as well....can I point the VM to that cconfig file?

0 Kudos
Josh26
Virtuoso
Virtuoso

Since differences in the config file will change the way that virtual disk is mapped, you would be far better served using the original config file.

You just need to use your datastore browser, find the file, and select "Import Virtual Machine" from the menu to load it.

0 Kudos
Ryguy01
Contributor
Contributor

I think I am missing something please bare with me. I recovered the entire directory that housed my VM including the .vmdk, .vmx, .vmxf, .vmsd, etc. from my ESXi 3.5 server. I copied this to the datastore on my ESXi 4.0 server. I opened up the Vsphere Client, setup a new VM using custom and selected the VMDK from the datastore directory. When I did that it created a new directory and created the vmx files in that new directory. Is there a way for me to tell it use the files in the directory I copied?

0 Kudos
Josh26
Virtuoso
Virtuoso

Are you able to delete this VM and all its files and start with a fresh recovery?

As stated earlier, you should browse the datastore and import the existing VM, rather than trying to create a new one.

0 Kudos
Ryguy01
Contributor
Contributor

I removed the VM and used the datastore as you suggested...thank you by the way....and now it is using the original config file. Unfortunately I am still getting the same GRUB error when i boot the VM....UGH. This may be a Ubuntu issue now. Do you think the VMDK is corrupt?

0 Kudos
nikolaricci
Contributor
Contributor

Moving ESXi 4 VMDK to Esxi 3.5

If someone want to move vmdk i oposite direction from esxi 4.0 to 3.5.

I have succeded with disk where I have installed win2k3x86.

You have to edit version of your virtual disk:

1. connect to vmhost to CLI, I did it via ssh

2. open <diskname>.vmdk file vith VI editor  (not <diskname>-flat.vmdk)

3. find line ddb.virtualHWVersion = "7" and change verison number to 4

4. and save file.

0 Kudos
raghavendrats
Contributor
Contributor

You can also use VMware Converter to recreate the VMDK files and host it on ESX 4.

0 Kudos
nikolaricci
Contributor
Contributor

Yes I know, firstly I used VMware Converter, but few times conversion were failed. The way I've discribed was alternative. Also I've experienced very slow conversion, depends of what kind of source vm.

0 Kudos