Re: [libvirt] [RFC v2] Export KVM Host Power Management capabilities
On Tue, Aug 09, 2011 at 11:25:28AM +0530, Vaidyanathan Srinivasan wrote:
* Eric Blake <eblake(a)redhat.com> [2011-08-05 10:32:31]:
> On 08/05/2011 10:11 AM, Daniel P. Berrange wrote:
> >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.
I tend to agree
> 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.
I wold try to implement something based on this.
What I think is important is make sure we don't implement a NodeSuspend
API if there is a risk of being trapped and not being able to wake up
the node from the API. And that means that we must be able to make the
resume from the node itself. An RTC timer is the best way to do this.
But I think this requires a change of API.
If we agree we can't rely on an external node wake up, and since the
connection is likely to drop after the Node actually goes to sleep
(either by explicit client close or because of the TCP/IP timeout),
we can't expect a libvirt API like virNodeResume() to work.
So I believe the API we need to to tell a node to go to sleep for a
given duration, the call will fail if we fail to set up the RTC wakeup
(and at libvirtd init time we should make sure the RTC does work). Maybe
the host will wake up earlier for some reason, but the management layer
knows that after that duration it should be able to reopen a connection
to the Node , then it can decide to send it back to sleep if it still
not needed, but at least from an API point of view this is complete.
Agreed, we would definitely like to have this feature exploited
through libvirt, we can cleanly suspend without using an external
program.
I'm fine with that as long as we are garanteed we can also resume
without using an external program too.
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/