Error: The destination host is not compatible with the hardware version to which the VM is scheduled to be upgraded

I scheduled a large number of VMs (find the script here) to upgrade the virtual hardware to the latest version.

Unfortunately, one VM ran into an issue and it was not possible to perform a vMotion or power it on anymore.

Every vMotion or Power-on actions failed with the following general system error:

A general system error occurred:

The destination host is not compatible with the hardware version to which the VM is scheduled to be upgraded. In order to proceed with the operation, VM’s scheduled compatibility upgrade should be disabled.

The hardware version displayed in the vSphere Web client was vHW 11. Everything looked fine, no VM Compatibility Upgrade was scheduled. So I tried to remove the VM from inventory and re-add it, but the error persisted.

Resolution:

It was necessary to delete three lines in the .vmx file:

  • power off the VM (if it is still running…)
  • remove the VM from inventory
  • make a copy of the .vmx file of affected VM (backup is always a good idea)
  • open the .vmx file in an editor and delete the following three lines:

tools.upgrade.policy = “upgradeAtPowerCycle”
virtualHW.scheduledUpgrade.when = “always”
virtualHW.scheduledUpgrade.state = “done”

  • add the VM to inventory
  • power-on the VM
  • check if the error persists

Note:
“Check and upgrade Tools during power cycling” is not active any more. You have to re-enable this setting if necessary (VM Settings – Edit Settings – VM Options – Tools Upgrade)

If the VM was part of a DRS rule you have to take care that you re-add it if necessary.

4 Comments

  1. deepika Analy

    Excellent post. very interesting to read. Thanks for sharing

    Data Warehousing Training in Chennai

  2. James Krolak

    Ran into this same issue this week. Showed my coworker this blog and he came up with a way to fix this via powershell that doesn’t require shutting down the VMs. Hopefully, this formats well enough when I post it here. Obviously, replace the blank line with the name or IP of your vCenter server. This one applies to all VMs in the environment. If you want to just focus on 1 or more, then change the “$vms = ” line.

    import-module vmware.vimautomation.core
    import-module vmware.vimautomation.vds
    Connect-VIServer _______________

    $vms = Get-VM
    foreach ($vm in $vms)
    {
    write-host “$($vm.name)”
    $vmguest = $vm | Get-VMGuest

    write-host $vmguest.OSFullName

    $vmview = $vm | Get-View
    $vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
    $vmConfigSpec.Tools = New-Object VMware.Vim.ToolsConfigInfo
    $vmConfigSpec.Tools.ToolsUpgradePolicy = “manual”
    $vmview.ReconfigVM($vmConfigSpec)

    $spec = New-Object -TypeName VMware.Vim.VirtualMachineConfigSpec
    $spec.ScheduledHardwareUpgradeInfo = New-Object -TypeName VMware.Vim.ScheduledHardwareUpgradeInfo
    $spec.ScheduledHardwareUpgradeInfo.UpgradePolicy = “never”
    $spec.ScheduledHardwareUpgradeInfo.ScheduledHardwareUpgradeStatus = “none”
    $vm.ExtensionData.ReconfigVM_Task($spec)
    $vm.ExtensionData.Config.ScheduledHardwareUpgradeInfo

    } # end foreach ($vm in $vms)

  3. Jau-Ling Chou

    Any idea why this is happening? we’ve been upgrading our VMs from v8 to v13, and maybe 1-2 VMs out of a thousand exhibit this issue. KB2080107 seems to state the issue, but there is no root cause. That KB article also lists only VMware ESXi 5.5.x as the product affected by the issue, but we’re running ESXi 6.5.

  4. Google Play Store Customer Service

    If the destination host is not compatible with the version then it is useless to run the program as it will not be successful at the end of the programming. Thus to know about the reason behind it or to fix the error the post can be helpful.

Leave a Comment

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