* Daniel P. Berrange <berrange@xxxxxxxxxx> [2011-08-08 16:38:48]: > On Fri, Aug 05, 2011 at 11:52:07PM +0530, Vaidyanathan Srinivasan wrote: > > * Daniel P. Berrange <berrange@xxxxxxxxxx> [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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list