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.


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

“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.


  1. 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 “$($”
    $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”

    $spec = New-Object -TypeName VMware.Vim.VirtualMachineConfigSpec
    $spec.ScheduledHardwareUpgradeInfo = New-Object -TypeName VMware.Vim.ScheduledHardwareUpgradeInfo
    $spec.ScheduledHardwareUpgradeInfo.UpgradePolicy = “never”
    $spec.ScheduledHardwareUpgradeInfo.ScheduledHardwareUpgradeStatus = “none”

    } # end foreach ($vm in $vms)

  2. 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.

  3. roadrunner email error 501

    Before running the script you need to connect to vCenter server by using Connect-VIServer cmdlets

  4. delete hacked aol account

    See the official Virtual Machines Hardware versions KB from VMware found… the Veeam Restore VM hardware version is not supported by destination host

Leave a Comment

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