One common method to verify that the system has the hardware virtualization extentions (Intel VT or AMD-V) required for full virtualization is to look into /proc/cpuinfo like:
egrep '(vmx|svm)' --color=always /proc/cpuinfo
There was an intriguing post by pjwelsh in the CentOS forums . Apparently he has a VT-capable CPU but it did not show up in /proc/cpuinfo. When he tried Fedora, it was there.
When someone as knowledgeable as pjwelsh reports an issue, it really needs attention but the thread did not yield any answer.
Then more recently, a post that seemingly reports the same problem appeared in the Forums. It was time to do more investigation.
Turns out it was a known issue and there was an entry in the Red Hat bugzilla explaining how that happened.
As work for 5.5 we masked out a bunch more cpuid flags, one of which was vmxe. This has caused some confusion since many people are used to looking in /proc/cpuinfo for vmx in order to detect if the hardware is capable of virtualization. To avoid the confusion, we’ll bring it back. It does, however, open a door for a guest admin to shoot themselves in the foot (i.e. attempt to load the KVM module on a Xen guest, which will crash the guest). The svm flag for AMD machines is also brought back.
Hmmm, seems over-cleaning to me. The fix was applied as of kernel-2.6.18-194.17.1.el5.
How did this get by QC? Linux is supposed to be all about transparency and openness giving those of us who troubleshoot for a living a clue. Please, vendors, let’s NOT turn the kernel into another “user friendly” mask-complexity-for-the-masses debacle. IT is littered with examples already. Just today I had need to troubleshoot based on these flags being available. Noticed they were not (CentOS 6, Scientific 6, RHEL 6) all 2.6.32.x kernels. If a “guest admin” shoots themselves in the foot–good. If they’re paying attention they might learn something.