Description of problem: This is a specific facet of 541294 but it comes up often enough to get its own bug. When /distribution/inventory is run on any ia64 system, it reports HVM=0 into the database. This is incorrect on at least half of the ia64s we have. The aggravation here is compounded by the fact that scripted changes are apparently not logged. Searching a system's history can show the HVM value being manually changed to "1", but it will be "0" in the DB if the inventory script has been run since.
(In reply to comment #0) > The aggravation here is compounded by the fact that scripted changes are > apparently not logged. Searching a system's history can show the HVM value > being manually changed to "1", but it will be "0" in the DB if the inventory > script has been run since. This is bug 658503 which is slated for 0.6.0.
(In reply to comment #0) > When /distribution/inventory is run on any ia64 system, it reports HVM=0 into > the database. This is incorrect on at least half of the ia64s we have. Do you have any hints as to how I can detect hardware virtualisation support on ia64? Right now the scripts test for the presence of the kvm_amd or kvm_intel kernel module, which is only going to work on x86_64: KVM support exists for ia64 but it appears to be unsupported and we don't ship it. Xen is frustratingly vague [1] about what is required for HVM support on ia64. There is also nothing interesting which I can see in /proc/cpuinfo.
The missing link for my previous comment: [1] http://wiki.xen.org/xenwiki/XenIA64/HowTo
I had a look at the Xen source, at arch/ia64/vmx/vmx_init.c:109 it uses some magic to fetch available processor features and then tests for a particular bit which indicates HVM support. I found the same information exported to userspace in /proc/pal/cpu0/processor_info, so our script could look in there to see if the necessary bit is set.
This is fixed in /distribution/install 1.1-38, which is now live. http://git.fedorahosted.org/git?p=beaker.git;a=commitdiff;h=724586b09bb0214b734c087e6d60bee176ade303
(In reply to comment #5) > This is fixed in /distribution/install 1.1-38 This was of course a typo, I meant /distribution/inventory