* Eric Blake <eblake@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