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.
Bug 836145 - Whitelist or blacklist guests that can enter suspend states
Summary: Whitelist or blacklist guests that can enter suspend states
Keywords:
Status: CLOSED DUPLICATE of bug 836462
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt
Version: 6.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Michal Privoznik
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-06-28 08:39 UTC by Amit Shah
Modified: 2013-01-23 10:36 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-09-10 07:06:24 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Amit Shah 2012-06-28 08:39:19 UTC
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.

Comment 2 Eric Blake 2012-06-28 11:57:59 UTC
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.

Comment 3 Amit Shah 2012-06-28 12:25:14 UTC
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.

Comment 6 Michal Privoznik 2012-09-10 07:06:24 UTC
After discussion with Amit I am closing this as dup.

*** This bug has been marked as a duplicate of bug 836462 ***


Note You need to log in before you can comment on or make changes to this bug.