[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] Start of freeze for libvirt-0.9.10 and availability of rc1



On Mon, Feb 13, 2012 at 03:39:51PM +0100, Jiri Denemark wrote:
> On Fri, Feb 10, 2012 at 13:33:47 -0700, Eric Blake wrote:
> > On 02/10/2012 12:21 PM, Dave Allan wrote:
> > >> I'm wondering if we're too late for one more API to round out the API we
> > >> added in this release.  Qemu is proposing a new monitor command
> > >> system_wakeup which lets the host inject a power-button wakeup to a
> > >> guest that has gone into S3 sleep.  Since we added the
> > >> virDomainPMSuspendForDuration command to put the guest into S3 from the
> > >> host, I think we need a counterpart API that wakes the guest back up,
> > >> rather than relying on mouse clicks, serial input, or timeouts doing the
> > >> job for us.  It's a shame that virDomainResume() has no flags argument,
> > >> and that it is already tied to virDomainSuspend() (aka guest pause), so
> > >> I'm thinking something like:
> > >>
> > >> /* Inject a wakeup into the guest that previously used
> > >>  * virDomainPMSuspendForDuration, rather than waiting for the
> > >>  * previously requested duration (if any) to elapse. */
> > >> int virDomainPMWakeup(virDomainPtr dom, unsigned int flags);
> > > 
> > > Just to throw this out there, could we not simply implement the rest
> > > of the power states in this API?  Kind of late to be asking this
> > > question, I suppose, but we haven't released this API yet, could we
> > > change its name to virDomainPMSetPowerStateForDuration?
> > 
> > Interesting idea!  It means we have one call, instead of 2, and 4 PM
> > states instead of 3 (suspend, hibernate, hybrid, and now wakeup).  Of
> > course, wakeup for duration doesn't make much sense, so we could
> > explicitly require a 0 duration for the wakeup case.
> 
> I'm not a big fan of this idea. There are two different things here:
> suspending (in whatever way) and waking up. I think it makes sense to have
> separate APIs for them. After all we don't have a virDomainSetState API which
> we could use to transition domain between lifecycle states (running, shutoff,
> paused, ...). We have separate APIs for each transition, each doing one
> "simple" thing and possibly taking different data needed for that transition.

Ok, fair enough; I just thought I'd better ask the question.

Dave

> Jirka


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]