Bug 460997 - HTS shouldn't report systems as PV if the "Model" or "Vendor" is unknown
HTS shouldn't report systems as PV if the "Model" or "Vendor" is unknown
Product: Red Hat Hardware Certification Program
Classification: Red Hat
Component: Test Suite (harness) (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: YangKun
Lawrence Lim
Depends On: 310861
  Show dependency treegraph
Reported: 2008-09-03 04:26 EDT by YangKun
Modified: 2014-03-25 20:55 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-27 17:58:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description YangKun 2008-09-03 04:26:25 EDT
Description of problem:

currently HTS will treat systems which "Model" or "Vendor" information is uncertain(can not be found by HTS) as PV guests. and record this PV info in the result rpm names. the related code is in hts/hts/hardwaretest.py :

634         if not (foundModel or foundVendor) and os.system("hal-device | fgrep -q xen") == 0:
635                 if self.Debugging: print "Running in a PV Guest"
636                 self.certification.setHardware(Tags.vendor, "Red Hat")
637                 foundVendor = True
638                 self.certification.setHardware(Tags.model, "ParaVirt Guest")
639                 foundModel = True

But the machines which "Model" and "Vendor" are unknown to HTS do exist, take this one as an example:

this is definitely not a PV guest.
Comment 1 Greg Nichols 2008-09-08 13:00:10 EDT
The current logic is only applied when there are hal devices with the string "xen" in them.
Comment 2 Rob Landry 2008-09-08 14:38:56 EDT
Isn't this already open a different bug to fix the PV vs. FV vs. Dom0 vs. BM which yk is already working on?
Comment 3 Rob Landry 2008-09-08 14:48:55 EDT
bug #310861 I believe?
Comment 4 YangKun 2008-09-09 02:13:59 EDT
(In reply to comment #1)
> The current logic is only applied when there are hal devices with the string
> "xen" in them.

I guess this is not enough to determine a system is PV ?
Comment 5 YangKun 2008-09-09 02:26:10 EDT
(In reply to comment #3)
> bug #310861 I believe?

this should be another issue, about the result rpm name. HTS will include both Vendor and Model information into the result rpm names. 

On the systems which has the string "xen" in the hal devices, if either "Model" or "Vendor" information is not available to HTS, HTS will treat it as PV. this is not correct because such machines that have the string "xen" in the hal devices when running on the "xen kernel" do exist, e.g.:
Comment 6 Rob Landry 2008-12-09 12:36:40 EST
YK, do you have patch for this that you'd like to propose?
Comment 7 YangKun 2008-12-10 21:57:14 EST
I'd suggest to simply remove this part of code from hts/hts/hardwaretest.py . there's no need to check if the system is PV here(bug#310861 will do that check). 

The purpose of "getBiosInfo()" is just to gather information for packaging the result rpm. it should proceed to "ask humans for it" if it can not find the machine model and vendor by it's own.

Do you agree with my suggestion ? If yes, then I can create the patch immediately.

Comment 8 Rob Landry 2008-12-11 17:45:23 EST
If Greg'll sign off on both patches works for me.
Comment 9 Greg Nichols 2008-12-12 11:03:54 EST
Sounds good to me.
Comment 11 YangKun 2008-12-14 20:38:24 EST
patch submitted, removed the PV checking here, please review.

Comment 12 Greg Nichols 2008-12-15 12:08:14 EST
Looks good to me.
Comment 18 Yan Tian 2009-01-15 02:14:39 EST
Verified in hts-5.3-12 hts would ask user input if the "Model" or "Vendor" was unknown and checked unknown field in result.xml file of "Model" or "Vendor".
Comment 20 errata-xmlrpc 2009-01-27 17:58:24 EST
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.


Note You need to log in before you can comment on or make changes to this bug.