Hide Forgot
Description of problem: accroding to "/usr/lib/python2.4/site-packages/sos/plugins/xen.py", the logic to check the system type is : if "/proc/acpi/dsdt" exist, then if "/proc/acpi/dsdt" contains "int-xen", then is FV if "/proc/xen/capabilities" exist, then if "/proc/xen/capabilities" contains "control_d", then is dom0 else is PV else is baremetal I verified this approach on RHEL5.2, it works well to distinguish PV guests. However, the checking for FV guests seems not effective, when a FV guest is running on a normal kernel, it will be reported as "baremetal", and when it is running on the "xen" kernel, it will be reported as "dom0". Version-Release number of selected component (if applicable): sos-1.7-9.2.el5
Hm, that seems extremely odd. When I originally wrote it, it definitely worked. To get "dom0", you would have to not only not have /proc/acpi/dsdt, you would also have to be running a -xen kernel in your FV guest. Something doesn't seem right. Can you give more details about your environment, including what you are running on the dom0, and inside the FV guest? Chris Lalancette
the machine is a Dell Precision490 workstation, I'll upload the sosreport tarball from both dom0 and the FV guest.
Created attachment 321740 [details] sosreport tarball from dom0 sosreport tarball from dom0
Created attachment 321741 [details] sosreport tarball from FV guest while the FV guest is running on the "normal" kernel sosreport tarball from FV guest while the FV guest is running on the "normal" kernel
OK. So the dom0 sosreport shows that it is doing the right thing; that is, it is saying "Xen hostType: dom0", which is exactly right. Ah, and now re-reading your original statement, I understand what you are talking about. Sorry I didn't understand at first. The first thing to note is to never, ever run the -xen kernel in a FV guest. While it seems to work, it tends to be very unstable, and you will not be happy with the performance or the stability. Regardless, however, the initial "/proc/acpi/dsdt" check should have prevented us from ever getting there, so something else is going on. And now I see it. We are currently checking for int-xen in /proc/acpi/dsdt, but in fact that was removed in RHEL 5.1, when we rebased the hypervisor. So this has been broken since then. There are a couple of alternative approaches I can try, including doing CPUID detection, and using DMI information. I'll look at them and report back. Chris Lalancette
Created attachment 321768 [details] Fix sos xen plugin HVM detection This patch fixes the HVM detection in the sos xen plugin. We were using an obsolete method of detecting whether we were in HVM; this fixes it up so that it works both on older RHEL-5, and newer RHEL-5.
Release note added. If any revisions are required, please set the "requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: The Xen plugin for sos was looking for the presence of fully virtualized guests by searching for int-xen in /proc/acpi/dsdt. Due to changes in how the Xen hypervisor is implemented in Red Hat Enterprise Linux, this approach does not work with updates newer than Red Hat Enterprise Linux 5.1. The Xen plugin now searches for xen in /proc/acpi/dsdt instead and can therefore identify fully virtualized guests.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2009-1418.html