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

[Vaidyanathan Srinivasan]

* 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