Red Hat Bugzilla – Bug 836145
Whitelist or blacklist guests that can enter suspend states
Last modified: 2013-01-23 05:36:54 EST
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:
Author: Daniel P. Berrange <firstname.lastname@example.org>
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>
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:
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.
After discussion with Amit I am closing this as dup.
*** This bug has been marked as a duplicate of bug 836462 ***