moshker
Contributor
Contributor

"One or more of the disks used by this virtual machine was created by an unsupported version"

Jump to solution

I used the converter to convert a physical server to vmworkstation vmdk's and then used vmkfstool -i to import the resulting vmdk's to one vmdk and a -flat.vmdk. I created a new vm and added the new vmdk as the disk, but when I try to start it I get "One or more of the disks used by this virtual machine was created by an unsupported version of VMware ESX Server. To power on or upgrade the virtual machine, either remove the unsupported disks(s) or use a version of VMware ESX Server that supports this version of the disks. Below is a list of the disks and their reported versions." Then it lists the correct path and vmdk as "Version 6". I've searched for this a bit, but I haven't found anything useful. I'm hoping someone here has a useful bit of advice.

I used converter 3..0.2 build 59994. The ESX host is version 3.02. The storage is NFS.

Any help is appreciated. Thanks in advance.

Oscar

0 Kudos
1 Solution

Accepted Solutions
SuperGrobi73
Enthusiast
Enthusiast

Hallo Moshker,

this is usual because after the import of a VMware Workstation VMDK the disk format is changed to a usable data file, but not the "index" file is correctly imported.

Remember:

In ESX one VMDK e.g. seen in Datastorebrowser consists of two files on the SAN, one very small whatever.vmdk and a big whatever-flat.vmdk.

When you import a Workstation VMDK the ESX builds these two files (see above) from your Workstation VMDK.

After vmkfstools -i was successfully done, ou can see the two files via COS / SSH. But the tool is clever and has seen that a Workstation 6 VMDK or Fusion 1.1.1 VMDK is in Version 6.

Solution:

Please open the whatever.vmdk usually about 388 k in size and change only the following entry:

ddb.virtualHWVersion = "6" to "4"

That's all!!!

To make this work you should remove your VM from Inventory and than "Add to Inventory" the VM again (But usually this works without a readd).

Have fun

Carsten

-- Mein Blog: http://www.datenfront.de

View solution in original post

0 Kudos
6 Replies
ponpalani2001
Hot Shot
Hot Shot

Hi,

Power-off the vm and try to upgrade the VM hardware from VC. Rightclick the vm and select upgrade and then power-on vm.

Added to the above point if the disks are created with IDE it will not work with ESX, so instead of exporting it through vmkfstools use vmware convertor to export the vmdk from vmware worstation to the ESX server and then power on the vm

Thanks

0 Kudos
moshker
Contributor
Contributor

When I right click the vm in the VI client when connected to our VC, "upgrade" isn't an option...

Confused,

Oscar

0 Kudos
ponpalani2001
Hot Shot
Hot Shot

Hi,

Check the disk if it is IDE or SCSI type. If it is IDE follow my added note in previous discussion.

Thanks

0 Kudos
SuperGrobi73
Enthusiast
Enthusiast

Hallo Moshker,

this is usual because after the import of a VMware Workstation VMDK the disk format is changed to a usable data file, but not the "index" file is correctly imported.

Remember:

In ESX one VMDK e.g. seen in Datastorebrowser consists of two files on the SAN, one very small whatever.vmdk and a big whatever-flat.vmdk.

When you import a Workstation VMDK the ESX builds these two files (see above) from your Workstation VMDK.

After vmkfstools -i was successfully done, ou can see the two files via COS / SSH. But the tool is clever and has seen that a Workstation 6 VMDK or Fusion 1.1.1 VMDK is in Version 6.

Solution:

Please open the whatever.vmdk usually about 388 k in size and change only the following entry:

ddb.virtualHWVersion = "6" to "4"

That's all!!!

To make this work you should remove your VM from Inventory and than "Add to Inventory" the VM again (But usually this works without a readd).

Have fun

Carsten

-- Mein Blog: http://www.datenfront.de

View solution in original post

0 Kudos
moshker
Contributor
Contributor

I love simple elegant answers. Thanks man! That totally did the trick.

0 Kudos
wdaleh
Contributor
Contributor

I searched for quite some time to find this answer.....well done!  You saved me a lot of time.

0 Kudos