Bug 867543 - (host_bios_info) PRD32 - RFE: collect host bios information
PRD32 - RFE: collect host bios information
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: RFEs (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 3.2.0
Assigned To: Yaniv Bronhaim
Tareq Alayan
: FutureFeature
Depends On:
Blocks: 915537
  Show dependency treegraph
Reported: 2012-10-17 12:43 EDT by Itamar Heim
Modified: 2016-02-10 14:10 EST (History)
11 users (show)

See Also:
Fixed In Version: sf4
Doc Type: Enhancement
Doc Text:
A range of hardware information, such as vendor, serial number and UUID, for each assigned host is now gathered upon assignment to the engine. This information can be accessed via the webadmin interface, under the host tab, in a sub tab labelled 'hardware-information'.
Story Points: ---
Clone Of:
Last Closed: 2013-06-10 17:14:28 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
dyasny: Triaged+

Attachments (Terms of Use)

  None (edit)
Description Itamar Heim 2012-10-17 12:43:05 EDT
various vendors need host level information for their plugin.

refresh rate should be via GetVdsCaps rate (i.e., on host status change)[1]

information should include at least BIOS Information, System Information, Base Board Information, Chassis Information.

source should be dmidecode-like

1. can't overload the entity trasnmitted to gui by default with all this info.

2. these fields should probably be made available though to plugins for quick decision making if to show the relevant vendor tab:
System Information.Manufacturer

3. some of these fields should probably be shown at UI level still at host general subtab
System Information
        Manufacturer: HP
        Product Name: ProLiant SL390s G7
        Version: Not Specified
        Serial Number: XXXXXXXX      
        UUID: 11111111111111111111111111111111111
        Family: ProLiant

[1] would be nice if we solve allowing to invoke GetVdsCaps refresh when standing on a host instead of forcing to move host to maint and back to up.
Comment 1 Miki Kenneth 2012-10-29 09:43:30 EDT
[1] this is more than nice !!!
Comment 6 Michael Pasternak 2012-11-20 11:20:19 EST
note: BIOS info should be exposed via api as well.
Comment 7 Barak 2012-11-21 03:06:52 EST
To summarize: 

1. VDSM will collect the following additional data:
 - Vendor
 - Product
 - Product Family
 - UUID (I'm almost sure we already report this one need to check it wasn't 
   changed in the last change of host unique ID done by alonbl)

2. Vdsm will return the value in getVdsCapabilities

3. engine will store this additional data in db

4. UI - Still not clear where we want it to be displayed, options:
 - Hosts tab / general subtab - it's a bit over loaded but it looks like there 
   is enough room.
 - We can add additional sub tab for Hardware and move all hardware related data 
 - We don't have to display it in UI 

5. This information needs to be available through API (+ sdk & cli)

Open issues:
* UI- see above
* use force refresh VDS capabilities ([1] in bug description), or simply add a 
  single call to getVdsCapabilities once it was added?
Comment 8 James Rankin 2012-11-21 08:27:43 EST
This information needs to be available via API, so that vendor plugins can retrieve it and act appropriately (ie display a UI plugin sub-tab if Product = X). I don't see a need for this to be in the generic UI.
Comment 10 Itamar Heim 2012-11-22 09:03:57 EST
(In reply to comment #8)
> This information needs to be available via API, so that vendor plugins can
> retrieve it and act appropriately (ie display a UI plugin sub-tab if Product
> = X). I don't see a need for this to be in the generic UI.

actually, you want the UI to pass this as part of entity to ui plugin (so uiplugin won't need to make a REST call to decide if to show something in context menu, or if to load or not a subtab).
(not available at this phase, in which we only pass the entity ID to ui plugins).
in any case, since the uiplugin passes entities based on the rest api modeling, it must be in the api modeling in any case
Comment 11 Yaniv Bronhaim 2012-11-25 04:21:55 EST
The information we can collect from the host by using dmidecode is full of varied data. Till now the feature only allows to collect the information as describe here: http://wiki.ovirt.org/wiki/Features/Design/HostBiosInfo (WIP) 

To figure which parameters we want to see there I arranged a list of all this bunch of information that we can collect, and its here for you to decide with examples from my computer. Tell me if something else is interesting. If we stay with only vendor, product type, and uuid it is quite short and can be added to hosts general tab (in the UI). But there are some more details that might be useful also: (I didn't include the fields we get about memory, processor and slots if those are also interesting please tell me and I'll add it to this list) 
   Family: ThinkPad T420s
   Manufacturer: LENOVO
   Product Name: 4174BH4
   SKU Number: Not Specified 
   Serial Number: R9M4N4G
   UUID: E03DD601-5219-11CB-BB3F-892313086897
   Version: ThinkPad T420s
   Type: Notebook
   Asset Tag: RH0003183
   BIOS Revision 1.31
   Characteristic x1 - ACPI: True
                       AGP: False
                       ATAPI Zip drive boot: False
                       I2O boot: False
                       IEEE 1394 boot: False
                       LS-120 boot: False
                       USB legacy: True
   Characteristic x2: BIOS boot specification: True
                      Function key-initiated network boot: True
                      Targeted content distribution: False
   3.5"/2.88 MB floppy services are supported (int 13h): False
   3.5"/720 KB floppy services are supported (int 13h): True
   5.25"/1.2 MB floppy services are supported (int 13h): False
   5.25"/360 KB floppy services are supported (int 13h): False
   8042 keyboard services are supported (int 9h): True
   APM is supported: False
   BIOS ROM is socketed: False
   BIOS is upgradeable: True
   BIOS shadowing is allowed: True
   Boot from CD is supported: True
   Boot from PC Card (PCMCIA) is supported: False
   CGA/mono video services are supported (int 10h): True
   EDD is supported: True
   EISA is supported: False,
   ESCD support is available: False
   ISA is supported: False
   Japanese floppy for NEC 9800 1.2 MB is supported (int 13h): False
   Japanese floppy for Toshiba 1.2 MB is supported (int 13h): False
   MCA is supported: False
   NEC PC-98: False
   PC Card (PCMCIA) is supported: False
   PCI is supported: True
   PNP is supported: True
   Print screen service is supported (int 5h): True
   Printer services are supported (int 17h): True
   Selectable boot is supported: True
   Serial services are supported (int 14h): True
   VLB is supported: False
   ROM Size: 8192 KB
   Relase Date: 11/29/2011
   Runtime Size: 128 KB
   Vendor: LENOVO
   Version: 8CET51WW (1.31 )
Comment 13 Barak 2012-12-25 10:30:35 EST
upstream patches:
vdsm:      http://gerrit.ovirt.org/#/c/9258/
           Adding getBiosInfo API to vdsm
engine:    http://gerrit.ovirt.org/#/c/10114/ 
           Adding host bios fields to vds_dynamic table

engine:    http://gerrit.ovirt.org/#/c/9337/
           Adding bios information to vds object

engine/ui: http://gerrit.ovirt.org/#/c/10115/
           Adding HostSubTab to UI for BIOS information
Comment 16 Yaniv Bronhaim 2013-01-20 10:13:20 EST
The name of BiosInfo was modified to HardwareInfo, because BIOS is a specific name for x86 arch on board program.

That means that comments, Wiki URL and the command name were modified to Hardware instead of Bios.

The command in vdsClient that initiates the request is getVdsHardwareInfo as mentioned in the following wiki page - http://wiki.ovirt.org/Features/Design/HostHardwareInfo
Comment 17 Tareq Alayan 2013-02-10 12:09:11 EST

Data appears on GUI, rest 

vdsClient -s 0 getVdsHardwareInfo
	systemFamily = Not Specified
	systemManufacturer = Dell Inc.
	systemProductName = PowerEdge R210 II
	systemSerialNumber = HLQGF5J
	systemUUID = 4C4C4544-004C-5110-8047-C8C04F46354A
	systemVersion = Not Specified
Comment 18 Cheryn Tan 2013-04-03 02:53:21 EDT
This bug is currently attached to errata RHEA-2013:14491. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag.

Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information:

* Cause: What actions or circumstances cause this bug to present.

* Consequence: What happens when the bug presents.

* Fix: What was done to fix the bug.

* Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')

Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug.

For further details on the Cause, Consequence, Fix, Result format please refer to:


Thanks in advance.
Comment 19 errata-xmlrpc 2013-06-10 17:14:28 EDT
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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