Re: [libvirt] [RFC v2] Export KVM Host Power Management capabilities
* Eric Blake <eblake(a)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