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

[Vaidyanathan Srinivasan]

* Daniel P. Berrange <berrange at redhat.com> [2011-08-08 16:38:48]:

> On Fri, Aug 05, 2011 at 11:52:07PM +0530, Vaidyanathan Srinivasan wrote:
> > * 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.
> 
> I really don't see that adding this to the capabilities enables any
> feature at all. As mentioned before, if you have to go outside of
> libvirt to control this feature, then having discovery in libvirt
> has near zero benefit. Adding the capability info as the first step
> is really the wrong way around. Only once we actually have some
> functionality related to this present in the libvirt API, is there
> any need to have discovery in libvirt. We don't want libvirt to be
> a general dumping ground for discovery of arbitrary host OS
> functionality, which is not controllable via libvirt.

Fair point.  As Eric also mentioned lets work out the mechanism to
invoke S3/S4 on host.  I am not opposed to designing the API for
invocation through libvirt, it will only help exploitation of this
power saving feature much better.  Lets continue discussion on Eric
API suggestion.

--Vaidy