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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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:
h
v.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.
thanks for this very useful post
___________________________________
description of vmx-parameters: http://sanbarrow.com/vmx.html
VMware-liveCD: http://sanbarrow.com/moa.html
Re-up please...
The link for the file is broken
The vt.iso link is working Ok for myself. If you send me a PM with your email I can send you a copy.
Dave
VMware Communities User Moderator
Now available - vSphere Quick Start Guide
Do you have a system or PCI card working with VMDirectPath? Submit your specs to the Unofficial VMDirectPath HCL .
Very usefull guide, I've lost several hours till I've found it.
the vt.iso link is working OK for me too.
useful, thanks
Good information,
thanks for sharing.
Nice tool, but I notice on my machine that the text scrolls too fast to read the output for all the cores in my system. I suspect when the tool was written that probably wasn't an issue (i.e., 4 cores would fit on screen OK).
Dear All
Catch from Intel could you advice if any intel CPU support Intel® 64 that mean needn't care about
VT-x&VT-d if support from cpu and I just can build up any Win2008 R2 at VM workstation?Thank you.
Advanced Technologies | |
Intel® Turbo Boost Technology | 2.0 |
Intel® vPro Technology | No |
Intel® Hyper-Threading Technology | Yes |
Intel® Virtualization Technology (VT-x) | Yes |
Intel® Virtualization Technology for Directed I/O (VT-d) | No |
Intel® Trusted Execution Technology | No |
AES New Instructions | Yes |
Intel® 64 | Yes |
Very useful, I had the same problem, VT-x was enabled but Workstation didn't recognize it.
Unplugging the PSU from electricity for a minute solved it.
I get the error when I pay the vmware player:
"Binary translation is incompatible with long mode on this platform. Disabling long mode. Without long mode support, the virtual machine will not be able to run 64-bit code."
My laptop doesn't support Hardware virtualisation. I don't see the word "virtual" under my BIOS setting.
My laptop info:
Windows7 Home premium
Running Mac OS X on non-Apple hardware is a violation of Apple's EULA and cannot be discussed here.
hi i have a problem to start the virtual machine some one help me
intel.com -> Product -> Product Specifications -> Advanced Search ->
https://ark.intel.com/content/www/us/en/ark/search/featurefilter.html?productType=873
I found here that my processor does not support VT-X technology