VMware Communities
MorganElevates
Contributor
Contributor
Jump to solution

"Unsupported hardware family" when transferring from esxi

When attempting to transfer a vm from esxi 6.5 free to VMware Fusion Pro via the "download from server", the system proceeds to download all 100GB of the VM, and only AFTER it has spent hours doing this, it gives a notice:

Screen Shot 2017-06-28 at 10.02.30 AM.png

(Unsupported hardware family 'vmx-12').

Worse, after churning through all that bandwidth and adding read/write cycles to my SSD's, it then deletes the "offending" VM from the destination machine, making me start over the whole tedious process from scratch.

While this may not technically be a bug, it is definitely in need of a fix, for two reasons:

1) It is very poor practice to not do such checks before undertaking large data transfers; and

2) It is poor practice to delete the file you just transferred while giving the user no opportunity to intervene to try to fix the problem.

It is unclear what the solution to the above problem is - so if anyone has an idea - that will be helpful. According to the documentation, hardware version 12 should be compatible with VMware Fusion Pro. But anyway, this silly programming is making things much harder to uncover and fix.

Morgan

1 Solution

Accepted Solutions
bluefirestorm
Champion
Champion
Jump to solution

I have some good news and I have bad news which may not apply to you; so maybe it isn't so bad.

Good news first: I managed to do a successful "Download from server" from an ESXi 6.5 using Fusion 8.5.7.

It looks to be a problem of the OVFTool. In the background Fusion would be calling the OVFTool. It is failing when it tries to convert the OVF into Fusion format. The OVFTool that came with Fusion 8.5.7 is version 4.1 and is missing an XML file called ovf-tool-hw12-config-option.xml. There could be more file differences and missing files necessary to support hw version 12.

You would have to download OVFTool 4.2.0.

https://my.vmware.com/group/vmware/details?productId=614&downloadGroup=OVFTOOL420

After I installed the OVF Tool 4.2. I then replaced the entire VMware OVF Tool folder located in

/Applications/VMware Fusion.app/Contents/Library/VMware OVF Tool

with the OVF Tool 4.2 installed

/Applications/VMware OVF Tool

I was then able to "Download from Server" 2 different VMs into Fusion and it created them and added to the VM library.

The bad news:

One of them didn't want to boot up from the virtual SCSI drive. I haven't figured out yet exactly why (and if possible to fix). For one thing the one that fail to boot up was created with EFI instead of BIOS. The other created with BIOS as virtual firmware booted up fine. As far as I can tell the only difference between them is the virtual firmware (BIOS vs EFI) in terms of VM configuration; disk they are both SCSI and thin-provisioned in ESXi 6.5. They are two different variants of Linux but I doubt if the OS matters; it should be more of the VM configuration.

View solution in original post

18 Replies
wila
Immortal
Immortal
Jump to solution

Hi,

Sorry, currently don't have the time to run a test here myself, but perhaps I can clarify some.

A VM has virtual hardware and this has several revisions.

For Fusion there is a virtual hardware version 12 and it is in the vmx file and looks like:

virtualHW.version = "12"

From the error that you are getting back it seems that vSphere 6.5 has put

virtualHW.version = "vmx-12"

in there and Fusion can't deal with that difference.

Personally I agree with your observations on how it should handle a failed download, but I guess that depends on where the error is.

It would be great if it first downloads the vmx and parses it for obvious errors before starting on downloading the big chunks.

But I don't work for VMware Smiley Happy so I don't know what the possibilities are.

--

Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
Reply
0 Kudos
MorganElevates
Contributor
Contributor
Jump to solution

Hi Wil,

Thanks for the feedback. Unfortunately, my config file on the esxi side already has this:

config.version = "8"

virtualHW.version = "12"

So I'm not sure what to change if it is already correct Smiley Sad

Morgan

Reply
0 Kudos
bluefirestorm
Champion
Champion
Jump to solution

Agree with your points about the way the error (or maybe even non-error) is handled.

But anyway, to the point of getting the VM running in Fusion 8.x Pro; since it is already HW version 12, it should be compatible.

You should be able to download the VM straight from the ESXi 6.5 datastore where the VM is stored using ESXi 6.5 UI HTML client (assuming that you have the appropriate access rights and know how to do it). After you download it, rename the folder with a .vmwarevm extension and it should become a VMware Fusion bundle that you can open in Fusion.

Should you decide to attempt the download and it doesn't work after downloading over 100GB, I disavow all responsibility. But -- this message will NOT self destruct in 5 seconds :smileylaugh:

Reply
0 Kudos
MorganElevates
Contributor
Contributor
Jump to solution

Hey bluefirestorm -

Thanks. Oddly, I tried downloading it from the web interface, and couldn't figure out how to do that.

When I go into the shell, the disks look like this:

diskname.vmdk  (a small text file)

diskname-flat.vmdk (the actual binary data store)

So, I navigate to that same spot in the Datastore Browser (GUI), and it only shows the single disk, i.e.

diskname.vmdk

While it shows this as being the full size - 37.46GB for this disk - when I hit "download" all it does is download the 525 byte text file (header).

It is quite likely I am missing something, but whatever I am missing renders the download process quite useless.

So, my latest attempt is using a 3rd party backup software (verticalbackup) to make a copy to my main system.

I am scratching my head at why this is such a difficult process? One of the reasons I bought VMWare Fusion Pro was to manage VMs on an esxi box, but so far the benefit is quite limited....

Thanks for any further insights.

Morgan

Reply
0 Kudos
bluefirestorm
Champion
Champion
Jump to solution

Sorry I should have checked first before replying about the download VM from UI client. I haven't tried the upload/download of an entire VM to/from datastore before thus the disavow statement. I have so far only downloaded/uploaded the vmx files but haven't paid attention to the actual files present in the datastore browser.

With your reply I did go in and check. It looks like the data store browser only exposes the descriptor (i.e. <disk name>.vmdk) in the UI client and not the entire set of VMDK. So that explains why you only got a 525 byte file. I also had the same experience as you did.

I would think because there are different virtual disk types and some disk types in ESXi will not work with Fusion/Workstation. Plus there could be complicated setups where a VM under ESXi refers to different virtual disks that resides in different datastores.

So on the surface, it does look unnecessarily complicated especially for relatively simple setups that are made intentionally to be compatible with Fusion/Workstation. I don't know if it will be so complicated if it is a paid ESXi version that comes with vCenter.

I don't know Vertical Backup but the point about renaming with the folder .vmwarevm extension should still be valid if Vertical Backup does not do it for you.

Reply
0 Kudos
wila
Immortal
Immortal
Jump to solution

Hi,

Ok, now I had time to test this against a vSphere 6.5 box in the lab and I see this:

pastedImage_1.png

Note that I removed the vmx file name from the picture.

This was a new VM, created for the purpose and using the latest vHW version, not seeing a workaround yet, will prod a bit and see if I can find something.

edit: This is indeed a virtual hardware issue.

While vSphere does not allow you to downgrade a VM, what you can do in a situation like this is:

1. Use VMware converter,

Or if you do not or cannot use that do what I did

2. Create a new VM and use the virtual disk from the VM you want to download

- unregister your VM (optional step, but recommended)

- create a New VM based on a lower virtual hardware default. For me a vSphere 6.0 worked, do not click past "Customize settings" yet

- Then remove the default hard disk it creates and attach the existing virtual disk from the VM you cannot download.

- Finish

Now download again.

--

Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
Reply
0 Kudos
bluefirestorm
Champion
Champion
Jump to solution

I have some good news and I have bad news which may not apply to you; so maybe it isn't so bad.

Good news first: I managed to do a successful "Download from server" from an ESXi 6.5 using Fusion 8.5.7.

It looks to be a problem of the OVFTool. In the background Fusion would be calling the OVFTool. It is failing when it tries to convert the OVF into Fusion format. The OVFTool that came with Fusion 8.5.7 is version 4.1 and is missing an XML file called ovf-tool-hw12-config-option.xml. There could be more file differences and missing files necessary to support hw version 12.

You would have to download OVFTool 4.2.0.

https://my.vmware.com/group/vmware/details?productId=614&downloadGroup=OVFTOOL420

After I installed the OVF Tool 4.2. I then replaced the entire VMware OVF Tool folder located in

/Applications/VMware Fusion.app/Contents/Library/VMware OVF Tool

with the OVF Tool 4.2 installed

/Applications/VMware OVF Tool

I was then able to "Download from Server" 2 different VMs into Fusion and it created them and added to the VM library.

The bad news:

One of them didn't want to boot up from the virtual SCSI drive. I haven't figured out yet exactly why (and if possible to fix). For one thing the one that fail to boot up was created with EFI instead of BIOS. The other created with BIOS as virtual firmware booted up fine. As far as I can tell the only difference between them is the virtual firmware (BIOS vs EFI) in terms of VM configuration; disk they are both SCSI and thin-provisioned in ESXi 6.5. They are two different variants of Linux but I doubt if the OS matters; it should be more of the VM configuration.

wila
Immortal
Immortal
Jump to solution

The bad news:

One of them didn't want to boot up from the virtual SCSI drive.

Interesting..

I just did the other way around and uploaded a VM with 2 virtual SCSI drives.

It also refused to boot.

--

Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
Mikero
Community Manager
Community Manager
Jump to solution

Thanks for digging in here guys, we're investigating.

-
Michael Roy - Product Marketing Engineer: VCF
wila
Immortal
Immortal
Jump to solution

Sorry for hijacking the thread, but I figure that when fixing this then fixing the upload might be just about as important.

Some more details.

When I uploaded during previous test I was not using the latest version of Fusion, I just reran the test with latest version of Fusion (8.5.8) against a vSphere 6.5 build 5310538 and still saw the same thing happening. It still did not boot. However when I just created a new vmx and attached the disks it booted fine.

The VM uses virtual hardware v11 and is a Windows 10 x64 VM with 2 hard disks.

So I compared the non working vmx with the working one and here is a list of the differences (I have ommitted any parts that are the same in both vmx files or that are certain to not be relevant like name/uuid etc..)

Broken vmx:

tools.upgrade.policy = "upgradeAtPowerCycle"

ide1:0.startConnected = "FALSE"

ide1:0.deviceType = "atapi-cdrom"

ide1:0.fileName = "CD/DVD drive 0"

ide1:0.present = "TRUE"

mks.enable3d = "TRUE"

ethernet0.virtualDev = "e1000"

mem.hotadd = "TRUE"

bios.hddOrder = "scsi0:1"

bios.bootOrder = "hdd"

tools.syncTime = "TRUE"

svga.vramSize = "67108864"

ethernet0.pciSlotNumber = "33"

ehci.pciSlotNumber = "34"

vmci0.pciSlotNumber = "35"

vmci0.id = "-331006865"

vm.genid = "-3425792894877841514"

vm.genidX = "-2389555672441898623"

vmotion.checkpointFBSize = "67108864"

vmotion.checkpointSVGAPrimarySize = "67108864"

softPowerOff = "FALSE"

Working vmx:

RemoteDisplay.maxConnections = "-1"

bios.bootRetry.delay = "10"

sched.cpu.units = "mhz"

sched.cpu.affinity = "all"

sched.cpu.latencySensitivity = "normal"

powerType.powerOff = "default"

powerType.reset = "default"

tools.upgrade.policy = "manual"

sata0.present = "TRUE"

sata0:0.deviceType = "atapi-cdrom"

sata0:0.fileName = "/vmfs/devices/cdrom/mpx.vmhba0:C0:T4:L0"

sata0:0.present = "TRUE"

svga.guestBackedPrimaryAware = "TRUE"

sched.scsi0:0.shares = "normal"

sched.scsi0:0.throughputCap = "off"

sched.scsi0:1.shares = "normal"

sched.scsi0:1.throughputCap = "off"

ethernet0.virtualDev = "e1000e"

tools.syncTime = "FALSE"

sched.cpu.min = "0"

sched.cpu.shares = "normal"

sched.mem.min = "0"

sched.mem.minSize = "0"

sched.mem.shares = "normal"

ethernet0.pciSlotNumber = "192"

ehci.pciSlotNumber = "33"

vmci0.pciSlotNumber = "34"

sata0.pciSlotNumber = "35"

vmci0.id = "1560783908"

vm.genid = "1531866820236198757"

vm.genidX = "6695202325794018109"

vmotion.checkpointFBSize = "4194304"

vmotion.checkpointSVGAPrimarySize = "4194304"

softPowerOff = "TRUE"

Hope this helps!

--

Wil

| Author of Vimalin. The virtual machine Backup app for VMware Fusion, VMware Workstation and Player |
| More info at vimalin.com | Twitter @wilva
MorganElevates
Contributor
Contributor
Jump to solution

Thanks for all the research into this problem guys!

Meanwhile, I found a way to transfer the VM's using a 3rd party tool (VerticalBackup).

However, I too have had to re-create VM's for the virtual hard drives when going back and forth between Fusion and esxi 6.5. It is inconsistent as to when it works and when it doesn't.

Fortunately, it looks like VMware folks are now aware of the issue and looking into it.

Morgan

Reply
0 Kudos
bluefirestorm
Champion
Champion
Jump to solution

The same set of problems (i.e. unsupported vmx-12, EFI VM downloaded couldn't boot up) exists at the Workstation 12.5.x side as the OVF Tool is also on 4.1 and missing the XML files.

Anyway to resolve the EFI boot problem, I just had to go download the nvram of the VM from the ESXi data store and copy it over to the Fusion bundle or Workstation VM folder and rename it as appropriate similar to this KB. And the EFI boot problem is resolved.

https://kb.vmware.com/kb/2061784

At the revision history of the OVF Tool 4.2 documentation, it mentions about support for EFI boot. But I couldn't find any option available to specify that the VM being exported to OVF/imported from OVF is an EFI VM. So perhaps the problem is simply the option is not being used by Fusion Pro 8.x and Workstation 12.5.x.

https://www.vmware.com/support/developer/ovf/ovf420/ovftool-420-userguide.pdf#page=7&zoom=auto,-271,...

Reply
0 Kudos
Graeme_R
Contributor
Contributor
Jump to solution

I am having a similar problem using VMWare Workstation 12 Pro (12.5.7 build-5813279) and ESXi 6.5 (6.5.0 Build 4887370)

I can create a VM in Workstation 12 Pro and upload it to ESXi 6.5, but when I try to download it back to Workstation 12 Pro, I get an 'Unsupported Hardware Family vmx-12' error.

What is really confusing is the various ways in which VMWare presents the 'Hardware Version'. In Workstation 12 Pro, the hardware versions are listed as compatible versions of Workstation, in the ESXi web interface, the list is by list of ESXi server versions, and in vSphere Client, they are listed as Virtual Machine Versions. Interestingly in vSphere Client, the numbering of hardware versions changes between 11 and 12. Up to version 11, the version is a straight number. From 12 onward, the version is vmx-xx (where xx is the version number)

Now in ESXi, the VM I created in Workstation 12 Pro is Hardware Version 12 (virtualHW.version = "12") - no sign of 'vmx-12', so the conversion between '12' and 'vmx-12' is part of the download process.

The only way I have been able to seamlessly upload and download between ESXi and Workstation 12 Pro is to create the VM using a hardware version prior to 12 (vSphere Client is the easiest to do this as I can clearly see the hardware versions).

Unfortunately, I have Hardware Version 12 VMs already created which I would like to be able to transfer seamlessly between ESXi (in the office for team based dev work) and Workstation 12 Pro (on my laptop for field based work)

Reply
0 Kudos
bluefirestorm
Champion
Champion
Jump to solution

Graeme,

If you read through this whole thread, one of the workaround/solution is already embedded in it.

You would have to download OVF Tool 4.2

https://my.vmware.com/group/vmware/details?productId=614&downloadGroup=OVFTOOL420

Similar to the VMware Fusion on macOS, after you install OVF Tool 4.2, you would then have to replace the OVFTool folder that came with Workstation Pro 12.

For Windows, assuming default folder locations, copy OVF Tool 4.2 from C:\Program Files\VMware\VMware OVF Tool folder and replace the entire folder in C:\Program Files(x86)\VMware\VMware Workstation\OVFTool folder. This way VMware Workstation Pro 12.5.7 would be invoking OVF Tool 4.2 that has the necessary files to support the hardware version 12 and 13 (ESxi 6.5).

Sorry I don't have Workstation Pro folder locations for Linux on hand, in case you are using Linux host, but the concept I assume would be the same.

Reply
0 Kudos
Graeme_R
Contributor
Contributor
Jump to solution

I did see the OVF Tool 4.2 solution and tried it. After replacing the OVF Tool folder with a copy of the 4.2 version, I could no longer select 'Download' in Workstation 12 Pro.

I just tried this again - I hadn't deleted the space between 'OVF' and 'Tool'

I can confirm that copying "C:\Program Files\VMware\VMware OVF Tool" to "C:\Program Files (x86)\VMware\VMware Workstation\OVFTool" fixes the problem

Hopefully VMWare will ship OVF Tool 4.2 with the next update of Workstation 12 Pro

Reply
0 Kudos
mfelker
Expert
Expert
Jump to solution

I have the same only with the wrinkle that my ESXi 6.5 server is in a VM.   I am running this machine both in Linux (Debian Sid w kernel 4.12) and Windows Server 2016 using WS Pro `12.5.7 for Linux and Windows respectfully.  I have 6 Linux distro running great on the ESXi 6.5 but I would like to detach (download) some to be a normal VM.   I uploaded some and created some directly in the ESXi server.  Now I always get a  "Download failed: Line25 Unsupportedf hardware family vmx-12" error.   I've thought os SSH into the ESXi VM and editing the vmx file for these machines (assuming I can find them :smileylaugh:) but it looks like from this thread that might be fruitless.  

Naturally if somebody has a solution other than just recreating the VM (which will take awhile since some like Debian, Tumbleweed and Ubuntu are up-to-date in with the unstable/devel builds (sid or artful for example. 

Somethignseems askew if you can upload a VM to a ESXi server but then can't download it).

Reply
0 Kudos
bluefirestorm
Champion
Champion
Jump to solution

@mfelker

The problem has nothing to do with the ESXi 6.5 being a VM itself. It is simply because of OVF Tool 4.1 that was installed with Workstation 12.x is missing the necessary XML schema files. When I tested out the OVF Tool 4.2 it was against an ESXi 6.5 VM running in Workstation 12.5.x in Windows.

You just need to download and installl the OVF Tool 4.2 which has the necessary XML files and replace the contents of the OVFTool folder that came installed with Workstation Pro

https://my.vmware.com/group/vmware/details?productId=614&downloadGroup=OVFTOOL420

By making a circular reference within this thread, you will also want to be aware of the problem with Linux VMs with EFI as firmware instead of BIOS Re: "Unsupported hardware family" when transferring from esxi

Reply
0 Kudos
SurferL
Contributor
Contributor
Jump to solution

Has an official fix been issued for this yet?

I'm using Fusion 8.5.x and ESX6.5 and had this issue as well.

Updating the OVF Tool seems to have fixed this issue for me, but I'm wary of the side effects which come with this...

Reply
0 Kudos