Trouble-shooting Intel VT-x Issues

    This document pertains only to Intel VT-x on Intel hardware. It does not pertain to AMD-V (aka SVM) on AMD hardware. Some portions of this document may be relevant to Intel VT-x on VIA hardware.

    Common Issues

    VT is enabled in the firmware, but your VMware product says that VT is disabled

    When a VMware product says that VT is disabled, it is referring to "Intel Virtualization Technology," otherwise known as VT-x.  Some firmware menus offer a separate setting for "VT-d," which is "Intel Virtualization Technology for Directed I/O."  Note that it is not sufficient to enable "VT-d."  You must enable "Intel Virtualization Technology." Moreover, the only VMware product that uses VT-d is ESX(i).  For other VMware products, the VT-d setting is irrelevant.

     

    Because the VT-x setting is typically locked at power on, it is necessary to fully power down the system after changing any VT-x options in the firmware (BIOS/EFI). A simple reboot is not sufficient! After saving your firmware changes, I recommend that you either switch off the power supply itself or pull the power cord(s) out of the wall and wait ten seconds. For laptop systems, you may have to remove the battery as well, although such extreme measures are rarely necessary.

     

    Note that VT-x is often unavailable to normal software if you have enabled "trusted execution," which may restrict the use of VT-x to "trusted" code. If you have enabled both VT-x and "trusted execution" in the firmware, but your VMware product still says that VT is disabled, disable "trusted execution" in the firmware and power-cycle the system again.  Your firmware menu may refer to "trusted execution" as "trusted computing."

     

    Sometimes, buggy firmware fails to enable VT on all of the cores of the system. To diagnose this issue, see "Obtaining Detailed Diagnostics," below.

    VT is disabled only after Windows 7 "Hybrid Sleep"

    If VT is enabled after a power-cycle, but it is disabled after hybrid sleep, the likely cause is buggy firmware (BIOS/EFI). The best solution is to obtain updated firmware from your system vendor. If this is not possible, or if the latest firmware does not resolve the issue, you may have to disable hybrid sleep. If the firmware leaves VT unlocked after hybrid sleep, current hosted VMware products will automatically enable and lock VT. A workaround exists for older VMware products. See "Enabling VT-x if Unlocked," below.

    VT is disabled only after hibernate and/or sleep

    If VT is enabled after a power-cycle, but it is disabled after hibernate and/or sleep, the likely cause is buggy firmware (BIOS/EFI). The best solution is to obtain updated firmware from your system vendor. If this is not possible, or if the latest firmware does not resolve the issue, you may have to disable hibernate and/or sleep. If the firmware leaves VT unlocked after hibernate and/or sleep, current hosted VMware products will automatically enable and lock VT. A workaround exists for older VMware products. See "Enabling VT-x if Unlocked," below.

    Your VMware product says that your host does not support VT

    Some Intel processors are not VT-capable. (For example, the Q8200 Intel Core 2 Quad Processor is not VT-capable). You can check to see if your processor(s) are VT-capable  here.

     

    If the Intel site says that your CPU(s) support VT, but your VMware product says that your host does not support VT, you may have encountered an Intel chip erratum (possibly AW67, AV69, AX64, AY64, AZ69 or AAA70, depending on the CPU). The effect of this erratum is that some CPU features are reported incorrectly by the CPU. The only solution to this problem is to obtain an updated BIOS from your system vendor.

     

    If you have a multi-processor system with mixed-stepping CPUs and the Intel site says that all of your CPU(s) support VT, but your VMware product says that your host does not support VT, your CPUs may support incompatible revisions of VT-x. This is known to be an issue with the "B" and "G" steppings of Intel processors codenamed "Clovertown" and "Woodcrest." The only solution to this problem is to obtain an updated BIOS from your system vendor.

    You are trying to run a nested VM with VT-x

    VMware products prior to ESXi 5.0, Workstation 8, and Fusion 4 do not virtualize the VT-x features of the physical CPU, so the virtual CPU will always report that the "host" does not support VT. In this case, the "host" refers to the virtual machine. If you are using ESXi 5.0, Workstation 8, or Fusion 4, see Running Nested VMs for information on enabling virtualized VT-x.

    You have McAfee Deep Defender installed on your host

    McAfee Deep Defender installs a hypervisor between the physical hardware and your host OS.  Thus, when you have McAfee Deep Defender installed, you are actually running the host OS in a VM.  McAfee Deep Defender does not virtualize the VT-x features of the physical CPU, so the virtual CPU will always report that the "host" does not support VT. In this case, the "host" refers to the virtual machine running under McAfee Deep Defender.

    Your firmware has no option to enable/disable VT

    If your firmware leaves VT unlocked at power-on, current hosted VMware products will automatically enable and lock VT. A workaround exists for older VMware products. See "Enabling VT-x if Unlocked," below.  However, if your firmware locks VT off at power-on (e.g. some Sony VAIO firmware), you may be out of luck. Sony VAIO users may want to search the forums for relevant threads, but please be aware that editing your CMOS settings with third-party tools can render your computer useless.

    You really are using SMX (trusted execution)

    Maybe you work for the NSA, and you really are running a VMware product under SMX.  There is a different bit that reports whether or not VT-x is enabled under SMX.  Unfortunately, there is no way to tell if the host operating system is running under SMX, so we assume that it isn't.  This means that the VMware product may be checking the wrong bit to see if VT-x is enabled.  A workaround is to set the following configuration option:

    hv.assumeEnabled = TRUE

    With this option set, VMware hosted products will assume that VT-x is available, regardless of the system configuration.

    Obtaining Detailed Diagnostics

    To verify that VT-x is enabled and locked on each core/thread of your system, download the attached ISO, burn it to a CD, and boot your host from the CD. Note that you must boot the physical machine from this CD image. It will do you no good to boot a VM from this image, since running this in a VM reports on the capabilities of the virtual CPU rather than the physical CPU.

     

    For each core on your system (or for each thread, if your CPU(s) support hyper-threading),  the ISO will report one or more of the following:

    CPU <n>: This core does not support long mode
    CPU <n>: This core does not support VT
    CPU <n>: Feature control MSR is unlocked!
    CPU <n>: VT is disabled in the feature control MSR!
    CPU <n>: VT is enabled on this core.

     

    This core does not support long mode

    If the ISO reports that some core(s) do not support long mode, you will not be able to use VT-x with current VMware products. You can use VT-x for 32-bit guests with Workstation 5.5 or 6.0.x, Fusion 1.x, or ESX 3.0, but this configuration is not supported. See  VMware Products and Hardware-Assisted Virtualization (VT-x/AMD-V).

    This core does not support VT

    If the ISO reports that some core(s) do not support VT, you will not be able to use VT-x. There are Intel CPU errata which may result in this capability being reported incorrectly. See "Your VMware product says that your host does not support VT," above.

    Feature control MSR is unlocked!

    If the ISO reports that some core(s) leave the feature control MSR unlocked, current VMware hosted products will automatically enable and lock VT. A workaround exists for older VMware products. See "Enabling VT-x if Unlocked," below.

    VT is disabled in the feature control MSR!

    If the ISO also reports that these core(s) leave the feature control MSR unlocked, current VMware hosted products will automatically enable and lock VT. A workaround exists for older VMware products. See "Enabling VT-x if Unlocked," below.  However, if the ISO reports that VT is disabled on some core(s) and it does not also report that the feature control MSR is unlocked on these core(s), then it is impossible to enable VT-x through software.

    Enabling VT-x if Unlocked

    This is already the default behavior for current VMware hosted products (Workstation 7.x, Player 3.x, and Fusion 3.x or newer). For older products, the following workaround may help if your firmware leaves VT-x unlocked, either at power-on, or after hibernate or sleep. Simply add the following option to your system-wide configuration file:

    hv.enableIfUnlocked = TRUE

    On Linux systems, the system-wide configuration file is /etc/vmware/config. On Windows systems, the system-wide configuration file varies according to VMware product and Windows version. For VMware Workstation on XP hosts, the system-wide configuration file is C:\Documents and Settings\All Users\Application Data\VMware\VMware Workstation\config.ini. For VMware Workstation on Vista or Windows 7 hosts, the system-wide configuration file is C:\ProgramData\VMware\VMware Workstation\config.ini. For other VMware products, adjust the path appropriately.