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 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list