[libvirt] [RFC v2] Export KVM Host Power Management capabilities
Vaidyanathan Srinivasan
svaidy at linux.vnet.ibm.com
Tue Aug 9 05:55:28 UTC 2011
* Eric Blake <eblake at redhat.com> [2011-08-05 10:32:31]:
> On 08/05/2011 10:11 AM, Daniel P. Berrange wrote:
> >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.
> >>
> >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.
>
> Does that mean that we need to add a new API:
>
> int virNodeSuspend(virConnectPtr conn, unsigned int flags)
>
> that returns 0 if the host will be suspended after a short delay
> (note that this must return before the suspend actually takes place,
> because after the suspend, the connection cannot return data until
> it resumes), and -1 where unsupported? Also, do we need to probe if
> the connection has a wake-on-lan capability or some other way to
> kick it back out of S3 or S4 when it is time to start using the node
> again?
We can easily implement the suspend part, but will have little
difficulty on the resume.
On the suspend front, we need an asynchronous mechanism to trigger
the suspend after say 5-10 seconds. Is there any other similar async
libvrit API that will return success before completing the action?
Next we will need a blocker flag indicating that the connection is
suspended, or maybe just terminate the connection.
For the resume, we have couple of methods:
* Resume on wake-on-lan and send the magic packet or kick from another
'nearby' node
* Have a timed sleep where we can wakeup on RTC alarm and check back
if there is new work, sleep again after a timeout.
* Explore other device based wakeup mechanism that can be easily
controlled from a libvirt client.
> I tend to agree with Dan's assessment that until there is something
> in libvirt that can make use of this information, then exposing it
> through libvirt is pointless. That is, if the only way to make use
> of the information is to call other programs, and since the
> information was obtained by another program, you haven't cut any
> other programs out of the loop by exposing the capability through
> libvirt. But if libvirt itself can be remotely told to suspend a
> host, then you've removed the need for external programs, and
> libvirt would indeed need to expose whether it supports the new
> feature of suspending a host.
Agreed, we would definitely like to have this feature exploited
through libvirt, we can cleanly suspend without using an external
program.
--Vaidy
More information about the libvir-list
mailing list