Suppressing CPU compatibility checks in vSphere 5.x

I have been meaning to post this information for ages, and fortunately after replying to a question in the VMware communities Andreas Peetz picked up on this and wrote a comprehensive article about these advanced settings, crucially explaining when to use them and why not to use them in production – thanks Andreas, excellent information!

So to save duplicating this, I have posted the summary here and if you want to read the full article, then head over to Andreas’s post – How to vMotion from Intel to AMD – and why not to do it.

Ok, these are vCenter advanced settings using the vSphere Client and give you some options of suppressing the CPU compatibility checks in vSphere 5.x when performing a vMotion operation.

Administration –> vCenter Server Settings –> Advanced Settings

Here is the sledgehammer approach;

config.migrate.test.CpuCompatibleWithHost = false
  • With this parameter set, all CPU-related compatibility testing throughout the vCenter Server are disabled.  If you have ESX/ESXi hosts on different hardware, the CPU compatibility won’t be tested, and this could have serious knock-on impacts to the VMs.

Given the risks, you may want to look at using one of the following instead;

config.migrate.test.CpuCompatibleMonitorSupport = false
  • With this parameter set, the “product version does not support features” errors will be suppressed, but other CPU compatibility errors will still be tested for.
config.migrate.test.CpuCompatibleError = false
  • With this parameter set, the CPU compatibility warnings will still be displayed in the migrate wizard, but they won’t block the migration.

Remember, these are unsupported and  not recommended for production environments … but extremely useful if ever needed, they have certainly saved me on a number occasions.

76,926 total views, 10 views today

Share on LinkedInShare on FacebookTweet about this on TwitterShare on Google+Digg thisShare on RedditPin on PinterestEmail this to someonePrint this page

Comments

  1. Mike Schreiner says:

    i used this years ago and it was great! Now, i am trying the same thing w/ Cisco C220 blades.
    i have a cluster w/ M2 and M3 blades. They don’t get along of course. I added the sledgehammer approach and i still get the CPU errors.

    • Hi Mike,
      What version of vSphere are you using? I’ve only tested this with version 5.0 and 5.1, so it’s possible that the settings have changed in newer versions.
      Cheers,
      Jon

  2. Mike Schreiner says:

    do i have to restart the vcenter services after this change?

  3. mike schreiner says:

    Hey Jon!
    It has been awhile. Have you had the chance to test this on vcenter 6?
    i have a couple VMs w/ this problem again.

  4. mike schreiner says:

    Hey Jon!
    It has been awhile. Have you had the chance to test this on vcenter 6?
    i have a couple VMs w/ this problem again.
    (Adding s second post so i get an email)

  5. Hi Jon !

    Have you tested in your LAB? I am interested in it. I work with vSPhere 6 too.

    Tank you,

  6. mike schreiner says:

    Hey Jon, have you been able to find anything on how to do this on vcenter 6?

Speak Your Mind

*