10:25 a.m.
Hi,
Linux host systems running KVM support various power management
capabilities. Most of the features like DVFS and sleep states can be
independently exploited by the host system itself based on system
utilisation subject to policies set by the administrator.
However, system-wide low power states like S3 and S4 would require
external communication and interaction with the systems management
stack in order to be used. The first steps in this direction would be
to allow systems management stack to discover host power saving
capabilities like S3 and S4 along with various other host CPU
capabilities.
Libvirt seems to be the main glue layer between the platform and the
systems-management stack. Adding host power savings capabilities as
part of libvirt host discovery mechanism seems to be one possible
approach without addition of any new APIs or agents.
libvirt has virConnectGetCapabilities() that would export an XML file
describing the capabilities of the host platform and guest features.
KVM hypervisor's capability to support S3 can be exported as a host
feature in the XML as follows:
<host>
<uuid>94a3492f-2635-2491-8c87-8de976fad119</uuid>
<cpu>
<arch>x86_64</arch>
<features> <<<=== New host feature fields
<S3/>
<S4/>
</features>
<model>Westmere</model>
<vendor>Intel</vendor>
<topology sockets='1' cores='2' threads='2'/>
<feature name='rdtscp'/>
<feature name='xtpr'/>
<feature name='tm2'/>
<feature name='est'/>
<feature name='vmx'/> <<<= These are host CPU features
System management software that works through libvirt, already queries
this capabilities XML file and hence no new API is needed.
As simple discovery mechanism can be added to libvirt as follows:
Index: libvirt-0.9.0/src/qemu/qemu_capabilities.c
===================================================================
--- libvirt-0.9.0.orig/src/qemu/qemu_capabilities.c
+++ libvirt-0.9.0/src/qemu/qemu_capabilities.c
@@ -738,6 +738,14 @@ virCapsPtr qemuCapsInit(virCapsPtr old_c
virCapabilitiesAddHostMigrateTransport(caps,
"tcp");
+ /* Add host energy management host capabilities */
+
+ /* if "pm-is-supported --suspend" == 0 */
+ virCapabilitiesAddHostFeature(caps, "S3");
+
+ /* if "pm-is-supported --hibernate" == 0 */
+ virCapabilitiesAddHostFeature(caps, "S4");
+
/* First the pure HVM guests */
for (i = 0 ; i < ARRAY_CARDINALITY(arch_info_hvm) ; i++)
if (qemuCapsInitGuest(caps, old_caps,
Please let me know your comments, I will code a working prototype
shortly and post for review/discussion.
Thanks,
Vaidy
3:56 p.m.
On Tue, Jun 28, 2011 at 08:55:31PM +0530, Vaidyanathan Srinivasan wrote:
Hi,
Linux host systems running KVM support various power management
capabilities. Most of the features like DVFS and sleep states can be
independently exploited by the host system itself based on system
utilisation subject to policies set by the administrator.
However, system-wide low power states like S3 and S4 would require
external communication and interaction with the systems management
stack in order to be used. The first steps in this direction would be
to allow systems management stack to discover host power saving
capabilities like S3 and S4 along with various other host CPU
capabilities.
Libvirt seems to be the main glue layer between the platform and the
systems-management stack. Adding host power savings capabilities as
part of libvirt host discovery mechanism seems to be one possible
approach without addition of any new APIs or agents.
Can you provide the use cases you're looking to address with this
work?
libvirt has virConnectGetCapabilities() that would export an XML
file
describing the capabilities of the host platform and guest features.
KVM hypervisor's capability to support S3 can be exported as a host
feature in the XML as follows:
<host>
<uuid>94a3492f-2635-2491-8c87-8de976fad119</uuid>
<cpu>
<arch>x86_64</arch>
<features> <<<=== New host feature fields
<S3/>
<S4/>
</features>
Just my $.02, but calling it <features> seems to be confusingly close
to the existing <feature> tag. Maybe <power_management> ?
<model>Westmere</model>
<vendor>Intel</vendor>
<topology sockets='1' cores='2' threads='2'/>
<feature name='rdtscp'/>
<feature name='xtpr'/>
<feature name='tm2'/>
<feature name='est'/>
<feature name='vmx'/> <<<= These are host CPU features
System management software that works through libvirt, already queries
this capabilities XML file and hence no new API is needed.
As simple discovery mechanism can be added to libvirt as follows:
Index: libvirt-0.9.0/src/qemu/qemu_capabilities.c
===================================================================
--- libvirt-0.9.0.orig/src/qemu/qemu_capabilities.c
+++ libvirt-0.9.0/src/qemu/qemu_capabilities.c
@@ -738,6 +738,14 @@ virCapsPtr qemuCapsInit(virCapsPtr old_c
virCapabilitiesAddHostMigrateTransport(caps,
"tcp");
+ /* Add host energy management host capabilities */
+
+ /* if "pm-is-supported --suspend" == 0 */
+ virCapabilitiesAddHostFeature(caps, "S3");
+
+ /* if "pm-is-supported --hibernate" == 0 */
+ virCapabilitiesAddHostFeature(caps, "S4");
+
/* First the pure HVM guests */
for (i = 0 ; i < ARRAY_CARDINALITY(arch_info_hvm) ; i++)
if (qemuCapsInitGuest(caps, old_caps,
Please let me know your comments, I will code a working prototype
shortly and post for review/discussion.
Dave
4:19 p.m.
On Fri, Jul 01, 2011 at 04:56:29PM -0400, Dave Allan wrote:
On Tue, Jun 28, 2011 at 08:55:31PM +0530, Vaidyanathan Srinivasan
wrote:
> Hi,
>
> Linux host systems running KVM support various power management
> capabilities. Most of the features like DVFS and sleep states can be
> independently exploited by the host system itself based on system
> utilisation subject to policies set by the administrator.
>
> However, system-wide low power states like S3 and S4 would require
> external communication and interaction with the systems management
> stack in order to be used. The first steps in this direction would be
> to allow systems management stack to discover host power saving
> capabilities like S3 and S4 along with various other host CPU
> capabilities.
>
> Libvirt seems to be the main glue layer between the platform and the
> systems-management stack. Adding host power savings capabilities as
> part of libvirt host discovery mechanism seems to be one possible
> approach without addition of any new APIs or agents.
Can you provide the use cases you're looking to address with this
work?
BTW, I'm intrigued by what you might be doing here, but I don't feel
like I have enough information at this point to know quite what to
think of it.
Dave
> libvirt has virConnectGetCapabilities() that would export an XML
file
> describing the capabilities of the host platform and guest features.
>
> KVM hypervisor's capability to support S3 can be exported as a host
> feature in the XML as follows:
>
> <host>
> <uuid>94a3492f-2635-2491-8c87-8de976fad119</uuid>
> <cpu>
> <arch>x86_64</arch>
> <features> <<<=== New host feature fields
> <S3/>
> <S4/>
> </features>
Just my $.02, but calling it <features> seems to be confusingly close
to the existing <feature> tag. Maybe <power_management> ?
> <model>Westmere</model>
> <vendor>Intel</vendor>
> <topology sockets='1' cores='2' threads='2'/>
> <feature name='rdtscp'/>
> <feature name='xtpr'/>
> <feature name='tm2'/>
> <feature name='est'/>
> <feature name='vmx'/> <<<= These are host CPU
features
>
> System management software that works through libvirt, already queries
> this capabilities XML file and hence no new API is needed.
>
> As simple discovery mechanism can be added to libvirt as follows:
>
> Index: libvirt-0.9.0/src/qemu/qemu_capabilities.c
> ===================================================================
> --- libvirt-0.9.0.orig/src/qemu/qemu_capabilities.c
> +++ libvirt-0.9.0/src/qemu/qemu_capabilities.c
> @@ -738,6 +738,14 @@ virCapsPtr qemuCapsInit(virCapsPtr old_c
> virCapabilitiesAddHostMigrateTransport(caps,
> "tcp");
>
> + /* Add host energy management host capabilities */
> +
> + /* if "pm-is-supported --suspend" == 0 */
> + virCapabilitiesAddHostFeature(caps, "S3");
> +
> + /* if "pm-is-supported --hibernate" == 0 */
> + virCapabilitiesAddHostFeature(caps, "S4");
> +
> /* First the pure HVM guests */
> for (i = 0 ; i < ARRAY_CARDINALITY(arch_info_hvm) ; i++)
> if (qemuCapsInitGuest(caps, old_caps,
>
>
> Please let me know your comments, I will code a working prototype
> shortly and post for review/discussion.
Dave
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
11:30 a.m.
* Dave Allan <dallan(a)redhat.com> [2011-07-01 17:19:06]:
On Fri, Jul 01, 2011 at 04:56:29PM -0400, Dave Allan wrote:
> On Tue, Jun 28, 2011 at 08:55:31PM +0530, Vaidyanathan Srinivasan wrote:
> > Hi,
> >
> > Linux host systems running KVM support various power management
> > capabilities. Most of the features like DVFS and sleep states can be
> > independently exploited by the host system itself based on system
> > utilisation subject to policies set by the administrator.
> >
> > However, system-wide low power states like S3 and S4 would require
> > external communication and interaction with the systems management
> > stack in order to be used. The first steps in this direction would be
> > to allow systems management stack to discover host power saving
> > capabilities like S3 and S4 along with various other host CPU
> > capabilities.
> >
> > Libvirt seems to be the main glue layer between the platform and the
> > systems-management stack. Adding host power savings capabilities as
> > part of libvirt host discovery mechanism seems to be one possible
> > approach without addition of any new APIs or agents.
>
> Can you provide the use cases you're looking to address with this
> work?
BTW, I'm intrigued by what you might be doing here, but I don't feel
like I have enough information at this point to know quite what to
think of it.
Hi Dave,
Thanks for taking a look. There are several advantages for using S3
or S4 state for the host system instead power 'off' and 'on' for
starting new guest instances. The main advantage of discovering the
capability through the systems management stack is to get the
capability reported after checking against all policies and software
compatibilities. The overall idea is to allow high level systems
management software that work through libvirt to discover and exploit
these capabilities wherever possible.
Discovery of available power savings features is only the first step
and I am looking for ideas to export these capabilities through
libvirt. I would expect the management stack that collects host
capabilities would be keep these feature list and could use them to
make various optimization decisions.
--Vaidy
4:23 p.m.
On Mon, Jul 04, 2011 at 10:00:20PM +0530, Vaidyanathan Srinivasan wrote:
* Dave Allan <dallan(a)redhat.com> [2011-07-01 17:19:06]:
> On Fri, Jul 01, 2011 at 04:56:29PM -0400, Dave Allan wrote:
> > On Tue, Jun 28, 2011 at 08:55:31PM +0530, Vaidyanathan Srinivasan wrote:
> > > Hi,
> > >
> > > Linux host systems running KVM support various power management
> > > capabilities. Most of the features like DVFS and sleep states can be
> > > independently exploited by the host system itself based on system
> > > utilisation subject to policies set by the administrator.
> > >
> > > However, system-wide low power states like S3 and S4 would require
> > > external communication and interaction with the systems management
> > > stack in order to be used. The first steps in this direction would be
> > > to allow systems management stack to discover host power saving
> > > capabilities like S3 and S4 along with various other host CPU
> > > capabilities.
> > >
> > > Libvirt seems to be the main glue layer between the platform and the
> > > systems-management stack. Adding host power savings capabilities as
> > > part of libvirt host discovery mechanism seems to be one possible
> > > approach without addition of any new APIs or agents.
> >
> > Can you provide the use cases you're looking to address with this
> > work?
>
> BTW, I'm intrigued by what you might be doing here, but I don't feel
> like I have enough information at this point to know quite what to
> think of it.
Hi Dave,
Thanks for taking a look. There are several advantages for using S3
or S4 state for the host system instead power 'off' and 'on' for
starting new guest instances. The main advantage of discovering the
capability through the systems management stack is to get the
capability reported after checking against all policies and software
compatibilities. The overall idea is to allow high level systems
management software that work through libvirt to discover and exploit
these capabilities wherever possible.
Discovery of available power savings features is only the first step
and I am looking for ideas to export these capabilities through
libvirt. I would expect the management stack that collects host
capabilities would be keep these feature list and could use them to
make various optimization decisions.
That certainly sounds useful to me.
Dave
1:24 p.m.
* Dave Allan <dallan(a)redhat.com> [2011-07-08 17:23:31]:
On Mon, Jul 04, 2011 at 10:00:20PM +0530, Vaidyanathan Srinivasan
wrote:
> * Dave Allan <dallan(a)redhat.com> [2011-07-01 17:19:06]:
>
> > On Fri, Jul 01, 2011 at 04:56:29PM -0400, Dave Allan wrote:
> > > On Tue, Jun 28, 2011 at 08:55:31PM +0530, Vaidyanathan Srinivasan wrote:
> > > > Hi,
> > > >
> > > > Linux host systems running KVM support various power management
> > > > capabilities. Most of the features like DVFS and sleep states can
be
> > > > independently exploited by the host system itself based on system
> > > > utilisation subject to policies set by the administrator.
> > > >
> > > > However, system-wide low power states like S3 and S4 would require
> > > > external communication and interaction with the systems management
> > > > stack in order to be used. The first steps in this direction would
be
> > > > to allow systems management stack to discover host power saving
> > > > capabilities like S3 and S4 along with various other host CPU
> > > > capabilities.
> > > >
> > > > Libvirt seems to be the main glue layer between the platform and the
> > > > systems-management stack. Adding host power savings capabilities as
> > > > part of libvirt host discovery mechanism seems to be one possible
> > > > approach without addition of any new APIs or agents.
> > >
> > > Can you provide the use cases you're looking to address with this
> > > work?
> >
> > BTW, I'm intrigued by what you might be doing here, but I don't feel
> > like I have enough information at this point to know quite what to
> > think of it.
>
> Hi Dave,
>
> Thanks for taking a look. There are several advantages for using S3
> or S4 state for the host system instead power 'off' and 'on' for
> starting new guest instances. The main advantage of discovering the
> capability through the systems management stack is to get the
> capability reported after checking against all policies and software
> compatibilities. The overall idea is to allow high level systems
> management software that work through libvirt to discover and exploit
> these capabilities wherever possible.
>
> Discovery of available power savings features is only the first step
> and I am looking for ideas to export these capabilities through
> libvirt. I would expect the management stack that collects host
> capabilities would be keep these feature list and could use them to
> make various optimization decisions.
That certainly sounds useful to me.
Let me get the next iteration of the patch out with working code.
This will allow us to review the implementation in more details.
Thanks,
Vaidy
11:35 a.m.
* Dave Allan <dallan(a)redhat.com> [2011-07-01 16:56:29]:
> libvirt has virConnectGetCapabilities() that would export an XML
file
> describing the capabilities of the host platform and guest features.
>
> KVM hypervisor's capability to support S3 can be exported as a host
> feature in the XML as follows:
>
> <host>
> <uuid>94a3492f-2635-2491-8c87-8de976fad119</uuid>
> <cpu>
> <arch>x86_64</arch>
> <features> <<<=== New host feature fields
> <S3/>
> <S4/>
> </features>
Just my $.02, but calling it <features> seems to be confusingly close
to the existing <feature> tag. Maybe <power_management> ?
Yes, I am open to naming the tag power_management. Any other similar
attributes that could be included here in future? Would calling it
power_management be very restrictive?
--Vaidy
4:22 p.m.
On Mon, Jul 04, 2011 at 10:05:21PM +0530, Vaidyanathan Srinivasan wrote:
* Dave Allan <dallan(a)redhat.com> [2011-07-01 16:56:29]:
> > libvirt has virConnectGetCapabilities() that would export an XML file
> > describing the capabilities of the host platform and guest features.
> >
> > KVM hypervisor's capability to support S3 can be exported as a host
> > feature in the XML as follows:
> >
> > <host>
> > <uuid>94a3492f-2635-2491-8c87-8de976fad119</uuid>
> > <cpu>
> > <arch>x86_64</arch>
> > <features> <<<=== New host feature fields
> > <S3/>
> > <S4/>
> > </features>
>
> Just my $.02, but calling it <features> seems to be confusingly close
> to the existing <feature> tag. Maybe <power_management> ?
Yes, I am open to naming the tag power_management. Any other similar
attributes that could be included here in future? Would calling it
power_management be very restrictive?
Urgh, busy week, sorry to be slow responding; I'd expect there will be
other features you'd want to describe, but they can have their own
tags.
Dave
1:28 p.m.
* Dave Allan <dallan(a)redhat.com> [2011-07-08 17:22:53]:
On Mon, Jul 04, 2011 at 10:05:21PM +0530, Vaidyanathan Srinivasan
wrote:
> * Dave Allan <dallan(a)redhat.com> [2011-07-01 16:56:29]:
>
>
> > > libvirt has virConnectGetCapabilities() that would export an XML file
> > > describing the capabilities of the host platform and guest features.
> > >
> > > KVM hypervisor's capability to support S3 can be exported as a host
> > > feature in the XML as follows:
> > >
> > > <host>
> > > <uuid>94a3492f-2635-2491-8c87-8de976fad119</uuid>
> > > <cpu>
> > > <arch>x86_64</arch>
> > > <features> <<<=== New host feature fields
> > > <S3/>
> > > <S4/>
> > > </features>
> >
> > Just my $.02, but calling it <features> seems to be confusingly close
> > to the existing <feature> tag. Maybe <power_management> ?
>
> Yes, I am open to naming the tag power_management. Any other similar
> attributes that could be included here in future? Would calling it
> power_management be very restrictive?
Urgh, busy week, sorry to be slow responding; I'd expect there will be
other features you'd want to describe, but they can have their own
tags.
Sounds good. Let me add a <power_management> tag within host and
perhaps outside of <cpu> since this is system attribute and not a CPU
attribute.
--Vaidy
4:42 a.m.
On Tue, Jun 28, 2011 at 08:55:31PM +0530, Vaidyanathan Srinivasan wrote:
Hi,
Linux host systems running KVM support various power management
capabilities. Most of the features like DVFS and sleep states can be
independently exploited by the host system itself based on system
utilisation subject to policies set by the administrator.
However, system-wide low power states like S3 and S4 would require
external communication and interaction with the systems management
stack in order to be used. The first steps in this direction would be
to allow systems management stack to discover host power saving
capabilities like S3 and S4 along with various other host CPU
capabilities.
Libvirt seems to be the main glue layer between the platform and the
systems-management stack. Adding host power savings capabilities as
part of libvirt host discovery mechanism seems to be one possible
approach without addition of any new APIs or agents.
libvirt has virConnectGetCapabilities() that would export an XML file
describing the capabilities of the host platform and guest features.
KVM hypervisor's capability to support S3 can be exported as a host
feature in the XML as follows:
<host>
<uuid>94a3492f-2635-2491-8c87-8de976fad119</uuid>
<cpu>
<arch>x86_64</arch>
<features> <<<=== New host feature fields
<S3/>
<S4/>
</features>
<model>Westmere</model>
<vendor>Intel</vendor>
<topology sockets='1' cores='2' threads='2'/>
<feature name='rdtscp'/>
<feature name='xtpr'/>
<feature name='tm2'/>
<feature name='est'/>
<feature name='vmx'/> <<<= These are host CPU features
System management software that works through libvirt, already queries
this capabilities XML file and hence no new API is needed.
As simple discovery mechanism can be added to libvirt as follows:
I agree with Dave that we need more information on the "big picture"
of what you are trying to achieve overall. Just adding a <s3/> or
<s4/> element on their own doesn't really seem useful to me, so I
imagine you must have more extensive plans not yet described ?
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 :|
11:45 a.m.
* Daniel P. Berrange <berrange(a)redhat.com> [2011-07-04 10:42:58]:
On Tue, Jun 28, 2011 at 08:55:31PM +0530, Vaidyanathan Srinivasan
wrote:
> Hi,
>
> Linux host systems running KVM support various power management
> capabilities. Most of the features like DVFS and sleep states can be
> independently exploited by the host system itself based on system
> utilisation subject to policies set by the administrator.
>
> However, system-wide low power states like S3 and S4 would require
> external communication and interaction with the systems management
> stack in order to be used. The first steps in this direction would be
> to allow systems management stack to discover host power saving
> capabilities like S3 and S4 along with various other host CPU
> capabilities.
>
> Libvirt seems to be the main glue layer between the platform and the
> systems-management stack. Adding host power savings capabilities as
> part of libvirt host discovery mechanism seems to be one possible
> approach without addition of any new APIs or agents.
>
> libvirt has virConnectGetCapabilities() that would export an XML file
> describing the capabilities of the host platform and guest features.
>
> KVM hypervisor's capability to support S3 can be exported as a host
> feature in the XML as follows:
>
> <host>
> <uuid>94a3492f-2635-2491-8c87-8de976fad119</uuid>
> <cpu>
> <arch>x86_64</arch>
> <features> <<<=== New host feature fields
> <S3/>
> <S4/>
> </features>
> <model>Westmere</model>
> <vendor>Intel</vendor>
> <topology sockets='1' cores='2' threads='2'/>
> <feature name='rdtscp'/>
> <feature name='xtpr'/>
> <feature name='tm2'/>
> <feature name='est'/>
> <feature name='vmx'/> <<<= These are host CPU
features
>
> System management software that works through libvirt, already queries
> this capabilities XML file and hence no new API is needed.
>
> As simple discovery mechanism can be added to libvirt as follows:
I agree with Dave that we need more information on the "big picture"
of what you are trying to achieve overall. Just adding a <s3/> or
<s4/> element on their own doesn't really seem useful to me, so I
imagine you must have more extensive plans not yet described ?
Hi Daniel,
This piece is the first step where the host feature is discovered and
exported. The systems management software that collects data from
various hosts would keep track of this feature list and exploit these
on supported systems. As I explained to Dave, discovering these
feature through libvirt has its advantages. But as you have noted
just discovering does not give us any advantages, but without
discovering, we will not be able to exploit the feature.
--Vaidy
4884
days inactive
4897
days old
10 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Dave Allan -
Vaidyanathan Srinivasan