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.
Description of problem:
Not all of our supported guests support S3/S4 states. libvirt should indicate to qemu whether a guest is capable of supporting that state, so that qemu can use the right bios definitions for the guest.
Example: all RHEL guests below version RHEL6.4 won't be able to properly resume from S3/S4 states, if they use virtio devices. This includes RHEL5 as well.
libosinfo should contain this information upstream. For RHEL6, if we're not including libosinfo, we must have a different way to do this.
Libvirt is too low-level to know which guest OS is installed in a VM; you may need to clone this bug to higher-level components like virt-install to create guests correctly in the first place based on attributes learned from libosinfo about what the guest should be able to support.
That said, libvirt _does_ need to provide a way to determine which bios to use, as part of the domain XML, so that the upper-level software sets this ability correctly based on whether the guest being installed supports S3/S4. However, this capability is _already_ present since 0.9.12:
commit ddf2dfa1f79af0405df5ca10583764a497c7a0db
Author: Daniel P. Berrange <berrange>
Date: Tue Apr 10 15:02:13 2012 +0100
Wire up <loader> to set the QEMU BIOS path
* src/qemu/qemu_command.c: Wire up -bios with <loader>
* tests/qemuxml2argvdata/qemuxml2argv-bios.args,
tests/qemuxml2argvdata/qemuxml2argv-bios.xml: Expand
existing BIOS test case to cover <loader>
But our docs are out of date, in not mentioning how to properly use the <loader> subelement in order to influence which bios is chosen:
http://libvirt.org/formatdomain.html#elementsOSBIOS
so this bug is definitely worth leaving open until that is resolved.
Indeed the support has to come from higher layers.
Note that there's another possibility to selecting a bios: qemu will gain a command line parameter to notify bios whether to advertise s3/s4 support or not. libvirt needs to insert this command line argument depending on whether the guest supports suspend functionality. I'll clone a bug separately for libvirt from the qemu bug for this new function.