Re: [libvirt] [PATCH 0/8] Introduce virDomainGetState API
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