* Eric Blake <eblake@xxxxxxxxxx> [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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list