Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionJ.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.
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).
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