Bug 310861
Summary: | HTS should notify user when run under PV guest | ||||||
---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Hardware Certification Program | Reporter: | Satyabrata Maitra <smaitra> | ||||
Component: | Test Suite (harness) | Assignee: | YangKun <ykun> | ||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Lawrence Lim <llim> | ||||
Severity: | low | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 5 | CC: | gnichols, rlandry, tools-bugs | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2009-02-24 17:30:59 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Bug Depends On: | |||||||
Bug Blocks: | 460997 | ||||||
Attachments: |
|
Description
Satyabrata Maitra
2007-09-28 13:15:09 UTC
Created attachment 210291 [details]
ia64-xen-EL5.1-hts-5.1.1-result
Changing product to test suite. It seems the package is for a para-virt guest which isn't technically supported but the failures from the catalog are because the package appears corrupted. *** Bug 313531 has been marked as a duplicate of this bug. *** *** Bug 313541 has been marked as a duplicate of this bug. *** The bug is that HTS should detect when it is running on a PV guest, and notify the user that HTS is not intended to run on a PV guest. Changing summary accordingly. Is there a more concrete way to verify that you're in a paravirt env. than just an error from dmidecode on a -xen kernel. I would think there are other possibilities for that condition to be true. (In reply to comment #9) > Is there a more concrete way to verify that you're in a paravirt env. than just > an error from dmidecode on a -xen kernel. I would think there are other > possibilities for that condition to be true. for what I know, checking the BIOS is an effective way. I don't have any other better idea to do this. -YK got another way from the virtualist, in "/usr/lib/python2.4/site-packages/sos/plugins/xen.py": ====================================== if os.access("/proc/acpi/dsdt", os.R_OK): (status, output) = commands.getstatusoutput("/usr/bin/strings /proc/acpi/dsdt | grep -q int-xen") if status == 0: return "hvm" if os.access("/proc/xen/capabilities", os.R_OK): (status, output) = commands.getstatusoutput("grep -q control_d /proc/xen/capabilities") if status == 0: return "dom0" else: return "domU" ====================================== should I change to use this method and write a new patch ? -YK What is the output from "grep -q control_d /proc/xen/capabilities" for each of dom0, domU-PV, domU-FV ? dom0: =================================== [root@dhcp-65-2 ~]# /usr/bin/strings /proc/acpi/dsdt | grep -q int-xen [root@dhcp-65-2 ~]# grep -q control_d /proc/xen/capabilities [root@dhcp-65-2 ~]# python Python 2.4.3 (#1, Jan 14 2008, 18:32:40) [GCC 4.1.2 20070626 (Red Hat 4.1.2-14)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import commands >>> (status, output) = commands.getstatusoutput("/usr/bin/strings /proc/acpi/dsdt | grep -q int-xen") >>> status 256 >>> (status, output) = commands.getstatusoutput("grep -q control_d /proc/xen/capabilities") >>> status 0 >>> [root@dhcp-65-2 ~]# =================================== domU-PV: =================================== [root@dhcp-65-126 ~]# /usr/bin/strings /proc/acpi/dsdt | grep -q int-xen /usr/bin/strings: '/proc/acpi/dsdt': No such file [root@dhcp-65-126 ~]# grep -q control_d /proc/xen/capabilities [root@dhcp-65-126 ~]# python Python 2.4.3 (#1, Jan 14 2008, 18:32:40) [GCC 4.1.2 20070626 (Red Hat 4.1.2-14)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import commands >>> (status, output) = commands.getstatusoutput("grep -q control_d /proc/xen/capabilities") >>> status 256 >>> [root@dhcp-65-126 ~]# =================================== domU-FV: =================================== [root@dhcp-65-117 ~]# /usr/bin/strings /proc/acpi/dsdt | grep -q int-xen [root@dhcp-65-117 ~]# grep -q control_d /proc/xen/capabilities [root@dhcp-65-117 ~]# python Python 2.4.3 (#1, Jan 14 2008, 18:32:40) [GCC 4.1.2 20070626 (Red Hat 4.1.2-14)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import commands >>> (status, output) = commands.getstatusoutput("/usr/bin/strings /proc/acpi/dsdt | grep -q int-xen") >>> status 256 >>> (status, output) = commands.getstatusoutput("grep -q control_d /proc/xen/capabilities") >>> status 0 >>> [root@dhcp-65-117 ~]# =================================== this approach also have to rely on a return value of a command to distinguish the domU-PV. |