Friday, December 2, 2011

VMware vMotion and the CPU incompatibility problem

By default, VirtualCenter only allows migrations with vMotion between compatible source and destination CPUs. So if you have been trying to move a VM from one host to another, and you got stuck with a error message telling you that the CPU of your destination host in incompatible with the CPU configuration of your Virtual Machine, then this usually means one of the following:

a) you did not mask the NX/XD bit in the settings of the VM or...
b) you did not enable the "No-Execute Memory Protection" on both your source host and destination host or...
c) you did not have your cluster of ESX hosts configured for Enhanced VMotion Compatibility (EVC)

The complete error message you get is:

CPU of the host is incompatible with the CPU feature requirements of virtual machine;
Problem detected at CPUID level 0x80000001 register edx 



There are different methods to get past this blocking point.

  • 1st method: hide the NX flag from the guest VM
  • 2nd method: enable a DEP mechanism on your hosts
  • 3rd method: enable EVC
The first method is to change the configuration of the VM to migrate in order to prevent it from checking the NX flag in the BIOS. This can be done either via the interface, either with a Powershell script. Let's explore both ways.

First method option A: to mask the Nx flag from the VI client, follow this procedure:
  • select the virtual machine from the Inventory
  • click Edit Settings
  • click Options
  • click Advanced
  • select "Hide the Nx flag from the guest".
  • OK

First method option B: If you want to accomplish this same task with Powershell, just customise and run the followjng ps1 script:

Add-PSSnapIn VMware.VimAutomation.Core
Connect-VIServer virtualcenterhost
filter Mask-NX {
    $view = get-view $_.id
    $vmConfigSpec = new-object VMware.Vim.VirtualMachineConfigSpec
    $featureMask = new-object VMware.Vim.VirtualMachineCpuIdInfoSpec
    $featureMask.info = new-object VMware.Vim.HostCpuIdInfo
    $featureMask.info.ecx = "---- -0-- ---- ---- ---- ---- ---- ----"
    $featureMask.info.level = 1
    $vmConfigSpec.CpuFeatureMask = $featureMask
    $view.ReconfigVM($vmConfigSpec)
}
Get-VM vm_name | Mask-NX

With a simple modification you could also use this script for modifying all the VMs inside a given cluster and taste your coffee while the job gets done. Just use Get-Cluster | Get-VM | Mask-NX instead of Get-VM vm_name | Mask-NX and your Powershell script will quickly cycle through each member of the cluster.

A second method is to have the "No-Execute Memory Protection" option enabled on both your source and destination host, so that they are at the same level. For your information, enabling this feature will protect your systems by marking all memory locations in a process as non-executable unless the location explicitly contains known executable code, and this will prevent against the execution of malicious code. This feature is also called DEP (Data Execution Prevention). To activate this option, do the following::

  • Reboot the server and access the BIOS
  • Select "Advanced Options"
  • Enable "No-Execute Memory Protection" (this is what is called on HP servers)
  • Press "F10" to save and the server will restart.
 
The third method, which is valid only for recent ESX versions, is to enable the EVC (Enhanced vMotion) mode, which is also useful you want to vMotion around all your VMs even if the source and destination hosts are not  running the same processor family (Intel, AMD). Here's the procedure:
  • Right click your cluster and choose Edit Setting
  • Click on the VMware EVC in the left panel
  • Select the option "Enable EVC for Intel Hosts" or "Enable EVC for AMD Hosts".
  • Now choose your VMWare EVC mode: you can raise the EVC mode to expose more CPU features, or lower the EVC mode in order to hide CPU features and increase compatibility with older hardware
  • Click Ok
 

Your problem should now be solved whatever method you used. The method you will choose is just a question of approach. Any administrator will choose differently depending on his environment/constraints.

I hope you have found the answer you were looking for and, if so, do not hesitate to comment!

1 comment:

  1. In either of the above option server shut down is mandatory specially in OPtion A.

    ReplyDelete

Related Posts Plugin for WordPress, Blogger...