Re: [libvirt] [PATCH] virConnectListAllDomains
On Fri, Aug 29, 2008 at 01:38:57PM +0100, Richard W.M. Jones wrote:
As observed in this thread:
https://www.redhat.com/archives/libvir-list/2008-July/msg00215.html
several tools need to grab the complete list of domains frequently
(eg. virt-manager and virt-top) and the way they do it currently is
very inefficient, both in terms of the number of round-trips in the
remote case (4 + 2*N calls), and the fact that we could implement
drivers better if we could get all domains in a single operation.
Therefore this patch adds the virConnectListAllDomains call:
int virConnectListAllDomains (virConnectPtr conn,
virDomainPtr **domains,
virDomainInfo **infos,
int stateflags);
This call gets domains and virDomainInfo structures. The reasons for
getting the info structures as well are that we get them anyway as a
side-effect of filtering on state, and virsh, virt-top and
virt-manager all get the info structures at the same time as getting
the domains.
The compatability code requires that you get all virDomainInfo objects
to filter by state, but a native implementation in the various drivers
will not neccessarily require this to be done. I agree we should
have the 'infos' parameter in the public API, it should be allowed
to be NULL though. Fetching the info for QEMU guests is not entirely
without costs of its own - read & parse several /proc/ files per
VM, and filtering can be done without this, since QEMU tracks the state
flag in libvirtd explicitly. Similarly for OpenVZ, fetching the
domain info may require invocation of several commands to query info
like CPU time.
As in Dan's proposal above, you can filter on state, with three
special values (VIR_DOMAIN_LIST_ACTIVE, VIR_DOMAIN_LIST_INACTIVE and
VIR_DOMAIN_LIST_ALL) which do what you think.
virConnectListAllDomains is always available. If the driver doesn't
implement it directly, then we emulate it in src/libvirt.c. This
ensures that virt-manager etc can start to use this call straightaway.
There is no direct implementation for Xen or QEMU yet. (If the
general patch is accepted, then I'll implement at least for QEMU).
However there is already a benefit to applying this patch because it
optimizes the remote case from 4 + 2*N calls down to 1.
I'd like to see an implementation of this working against XenD before
we commit this to API, since that's the driver which stands to gain
the most from the performance improvements this API ought to allow.
Regards,
Daniel.
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|