Re: [PATCH 0/8] Introduce virDomainGetState API

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

 



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.

> 
> 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.

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.

Obviously, this series is post-0.9.1.

-- 
Eric Blake   eblake@xxxxxxxxxx    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]