Bug 696238

Summary: [RFE] Report virtualisation host through BIOS/dmidecode data
Product: Red Hat Enterprise Linux 6 Reporter: J.H.M. Dassen (Ray) <rdassen>
Component: qemu-kvmAssignee: Virtualization Maintenance <virt-maint>
Status: CLOSED WONTFIX QA Contact: Virtualization Bugs <virt-bugs>
Severity: low Docs Contact:
Priority: medium    
Version: 6.1CC: bsarathy, gleb, juzhang, mkenneth, rbinkhor, syamazak, tburke, virt-maint
Target Milestone: rcKeywords: FutureFeature, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
: 696242 (view as bug list) Environment:
Last Closed: 2011-05-27 18:47:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 696242    

Description J.H.M. Dassen (Ray) 2011-04-13 16:35:57 UTC
2. What is the nature and description of the request?

Please enhance KVM such that guests can be aware of their host via dmidecode
(which i believe is via the bios). This may potentially be an option in the
machines libvirt profile (actually a command line option for kqemu) for people
who feel it would be a security problems.

For example, on our HP blades, in dmidecode we can tell in which enclosure they
reside.

ie.

Handle 0xCC00, DMI type 204, 11 bytes
HP ProLiant System/Rack Locator
Rack Name: G0CR-F05
Enclosure Name: mas06-en
Enclosure Model: BladeSystem c7000 Enclosure
Enclosure Serial: SGH820YRDJ
Enclosure Bays: 16
Server Bay: 8
Bays Filled: 1

Something similar to that, indicating the host system.


3. Why does the customer need this? (List the business requirements here)

This would allow us to know which host a guest is running on from within the
running guest. Without resorting to bulk virsh grepping or looking at the
network port.

4. How would the customer like to achieve this? (List the functional
requirements here)

- dmidecode output would include some details of the host
- these would change if the guest migrates
- optionally, the libvirt profile would allow this option to be triggered


5. For each functional requirement listed in question 4, specify how Red Hat
and the customer can test to confirm the requirement is successfully
implemented.

- confirm dmidecode output
- migrate guests and check dmidecode output

6. Is there already an existing RFE upstream or in Red Hat bugzilla?

Not aware of such RFE at the moment

7. How quickly does this need resolved? (desired target release)

ASAP

8. Does this request meet the RHEL Inclusion criteria (please review)

It seems to do so.

9. List the affected packages

qemu
kvm
libvirt

10. Would the customer be able to assist in testing this functionality if
implemented?

Yes.

Comment 2 Gleb Natapov 2011-05-16 19:36:49 UTC
This will not work with migration. dmi tables are static and cannot be updated after guest is migrated to another host. Guest agent should be used to retrieve such info (and of course the info can be out of date by the time it is retrieved so its usefulness is questionable).

Comment 7 Dor Laor 2011-05-30 06:33:06 UTC
A better alternative would be to use a guest agent that can retrieve the information from the host dynamically. This way live migration changes will be reflected. It should be delivered as part of the Matahari project