Monthly Archives: December 2010

Hardware virtualization supported but no vmx or svm flag?

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.

SELinux and FreeNX

[Note added in August 2011: Be sure to read the comment by Dan Walsh. There is a simpler solution]

When you attempt to connect to a remote machine using freenx, you might encounter this message:

The NX service is not available or the NX access was disabled on host XXX.

This is likely due to SELinux blocking the connection. If you are using QtNX, it just hangs without any message.  Here is how to solve the issue.

(1) Disable auditd.

service auditd stop

(2) Rename /var/log/audit/audit.log or move it somewhere else.

(3) Enable auditd

service auditd start

(4) Try connection from the client. It will fail. This writes the audit.log file.

(5) Generate SELinux policy rules from the log file and install it.

cat /var/log/audit/audit.log | audit2allow -M freenx
semodule -i freenx.pp

(6) You can see the policy by reading the .te file.

cat freenx.te

module freenx 1.0;

require {
type nx_server_var_lib_t;
type sshd_t;
class file read;
}

#============= sshd_t ==============
allow sshd_t nx_server_var_lib_t:file read;

(7) Now, try connecting from the client again. It will fail again. Repeat the steps (1) to (5) using ‘freenx2’ instead of ‘freenx’.

(8) You will most likely need to repeat the process yet one more time until the connection finally succeeds. So, once again repeat the steps (1) to (5) but this time using ‘freenx3’ instead of ‘freenx’.

If you look at the policy files generated, you will find what was added by each action.