Bug 836145 - Whitelist or blacklist guests that can enter suspend states
Whitelist or blacklist guests that can enter suspend states
Status: CLOSED DUPLICATE of bug 836462
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libvirt (Show other bugs)
6.3
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Michal Privoznik
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-28 04:39 EDT by Amit Shah
Modified: 2013-01-23 05:36 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-10 03:06:24 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Amit Shah 2012-06-28 04:39:19 EDT
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 07:57:59 EDT
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@redhat.com>
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 08:25:14 EDT
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 03:06:24 EDT
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.