[libvirt] [RFC v2] Export KVM Host Power Management capabilities

[Vaidyanathan Srinivasan]

* Daniel P. Berrange <berrange at redhat.com> [2011-08-05 17:11:50]:

> On Fri, Aug 05, 2011 at 05:24:13PM +0530, Srivatsa S. Bhat wrote:
> > This patch exports KVM Host Power Management capabilities as XML so that
> > higher-level systems management software can make use of these features
> > available in the host.
> > 
> > The script "pm-is-supported" (from pm-utils package) is run to discover if
> > Suspend-to-RAM (S3) or Suspend-to-Disk (S4) is supported by the host.
> > If either of them are supported, then a new tag "<power_management>" is
> > introduced in the XML under the <host> tag.
> > 
> > Eg: When the host supports both S3 and S4, the XML looks like this:
> > 
> > <capabilities>
> > 
> >   <host>
> >     <uuid>dc699581-48a2-11cb-b8a8-9a0265a79bbe</uuid>
> >     <cpu>
> >       <arch>i686</arch>
> >       <model>coreduo</model>
> >       <vendor>Intel</vendor>
> >       <topology sockets='1' cores='2' threads='1'/>
> >       <feature name='xtpr'/>
> >       <feature name='tm2'/>
> >       <feature name='est'/>
> >       <feature name='vmx'/>
> >       <feature name='pbe'/>
> >       <feature name='tm'/>
> >       <feature name='ht'/>
> >       <feature name='ss'/>
> >       <feature name='acpi'/>
> >       <feature name='ds'/>
> >     </cpu>
> >     <power_management>         <<<=== New host power management features
> >       <S3/>
> >       <S4/>
> >     </power_management>
> >     <migration_features>
> >       <live/>
> >       <uri_transports>
> >         <uri_transport>tcp</uri_transport>
> >       </uri_transports>
> >     </migration_features>
> >   </host>
> >      .
> >      .
> >      .
> > 
> > However in case the host does not support any power management feature,
> > then the XML will not contain the <power_management> tag.
> > 
> > The initial discussion about this patch was done in [1]. And the choice
> > to name the new tag as "power_management" was discussed in [2].
> > 
> > Please let me know your comments and feedback.
> 
> Exposing info in the capabilities is great, if applications can actually
> do something with this info. There are no APIs in libvirt for controlling
> the host OS power management state, so I don't see what use this XML
> addition is on its own. ie, if an application using libvirt has to resort
> to spawning  '/usr/sbin/pm-suspend' to actually do anything, then there's
> no real benefit to having this info in libvirt, so they have to go outside
> of libvirt anyway.
> 
> So while the XML design/proposal may well be fine, until we actually have
> some host power management control APIs in libvirt, I'm inclined to NACK
> this addition to capabilities.

As we discussed in the previous RFC, exporting the capability is only
the first step to allow systems management software to easily discover
the capability subject to platform policies.  Actual invocation of
S3/S4 currently has to be outside of libvirt because wakeup involves
some sort of out-of-band event.  The management software is expected
to handle the state transitions until we could device an in-band
method through libvirt.  However the discovery and policy implications
can be managed by the libvirt infrastructure instead of building
another framework.  

Similar to S3/S4 capability, other power management features like
cpufreq/cpuidle polices and power-performance bias can be exported and
controlled by libvirt through a similar mechanism with a good policy
management framework.

This features enables optimizations that are implemented above libvirt
layer and opens up opportunity to discover and use platform power
management features.

--Vaidy