Hide Forgot
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