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

On Fri, Aug 05, 2011 at 11:52:07PM +0530, Vaidyanathan Srinivasan wrote: > * Daniel P. Berrange <berrange(a)redhat.com&gt; [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.