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. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list