On Wed, May 04, 2011 at 10:40:38 -0600, Eric Blake wrote: > On 05/04/2011 08:45 AM, Jiri Denemark wrote: > > This new API solves several problems: > > > > - calling virDomainGetInfo for just getting domain status is an overkill since > > it may result in sending requests to guest OS > > - since virDomainGetInfo can hang when guest OS is not responding and it is > > used by virsh list, listing domains can hang > > - virDomainGetState provides additional info about what action led to domain's > > current state, which can be used instead of listening to domain events > > > > I'm undecided whether this API should support flags parameter or not. On one > > hand the API seems simple and focused enough not to allow any fine-tuning but > > on the other hand we've already had too many issues with APIs that didn't > > support flags. > > Time has proven that we may want the flags argument in the future, even > if we don't know why now. Definitely add it. Yeah, I'll do that. > > Another thing is that it would be nice to somehow report that a domain is > > running but libvirt is currently waiting for reply from hypervisor and is not > > able to do anything else with the domain until it gets the reply. In case of > > qemu driver, this translates to the driver being stuck in comunication with > > qemu monitor. I'm not sure if we should somehow integrate this into > > virDomainGetState API. Probably not. > > In fact, this may be a use for the flags! If flags is 0, then block > until the state information is available (that is, we wait for the qemu > response to the prior command, just like any other blocking command); if > flags is 1, then an additional state category that can tell us that some > other command is pending (that is, we have a non-blocking way to query > if some other blocking command is in progress). Compare to WNOHANG and > WNOWAIT flags of waitpid - sometimes you want to query instantly and get > extra return values, other times you want to block until the query > completes and hide the extra return values. This looks like a misunderstanding... virDomainGetState doesn't block if we're waiting for qemu reply since it doesn't need to talk to it. And that's one of the reason this API was introduced. What I meant was that even though virDomainGetState reports running (or even paused), it doesn't mean that we can do anything with the domain because it can be hung and not replying to monitor commands. > I'm also wondering if we should make the API flexible enough to tell > which blocking commands are currently pending, or even for how long a > command has been waiting for a qemu response. Thinking about it more, I feel like it would be better to introduce a new API for this purpose. An API that would check if we can operate a domain (virDomainIsOperable or whatever name we choose). That is, if we can send a command to hypervisor without blocking. In qemu context that would mean checking if we're waiting for qemu reply or not and if so, further details such as how long we've been waiting for it could also be provided. It wouldn't be very usable for checking in advance if it's safe to issue a command but applications could use that to detect if some of their commands got stuck in qemu monitor. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list