Red Hat Bugzilla – Bug 867543
PRD32 - RFE: collect host bios information
Last modified: 2016-02-10 14:10:55 EST
various vendors need host level information for their plugin.
refresh rate should be via GetVdsCaps rate (i.e., on host status change)
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:
3. some of these fields should probably be shown at UI level still at host general subtab
Product Name: ProLiant SL390s G7
Version: Not Specified
Serial Number: XXXXXXXX
 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.
 this is more than nice !!!
note: BIOS info should be exposed via api as well.
1. VDSM will collect the following additional data:
- 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)
* UI- see above
* use force refresh VDS capabilities ( in bug description), or simply add a
single call to getVdsCapabilities once it was added?
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.
(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
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
Product Name: 4174BH4
SKU Number: Not Specified
Serial Number: R9M4N4G
Version: ThinkPad T420s
Asset Tag: RH0003183
BIOS Revision 1.31
Characteristic x1 - ACPI: True
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
Version: 8CET51WW (1.31 )
Adding getBiosInfo API to vdsm
Adding host bios fields to vds_dynamic table
Adding bios information to vds object
Adding HostSubTab to UI for BIOS information
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
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
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.
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.