Red Hat Bugzilla – Bug 437216
virConnectListDefinedDomains isn't returning the names of active domains
Last modified: 2009-12-14 16:13:06 EST
(using libvirt-0.3.3-5.el5 on x86_64) virConnectListDefinedDomains returns only the number of inactive domains when called, and only stores the names of the inactive domains in the char ** argument passed. virConnectNumOfDefinedDomains returns the expected number of domains (the sum of active and inactive domains) when called.
Created attachment 297859 [details] little reproducer program output for me: [root@celaeno tmp]# ./rhbz437216a1 virConnectNumOfDefinedDomains ret 7 virConnectListDefinedDomains ret 5 0 -> rhel46v3 1 -> r52_4 2 -> r52_3 3 -> r52_2 4 -> r52_1 5 is NULL 6 is NULL
That's normal, it really is the semantic of "defined domain", i.e. there is a definition for them but they are not running. Also it's way easier to have 2 entry point in the API doing a partition of the domain set than having to compute the diff between two lists if you want to be able to display the list of domain defined but not running. Not a bug, a misunderstanding of "DefinedDomains" semantic, Daniel
For virConnectNumOfDefinedDomains this looks like a bug, yes Daniel
It'd be helpful to update the docs to reflect that virConnectListDefinedDomains() is not supposed to return the active domains. For the other virConnectListDefined* functions, the docs explicitly state that only inactive entities are to be returned.
I think the bug is in xenXMNumOfDefinedDomains() affecting basically only Xen in RHEL-5.x (x >= 1), as it lists the number of files but doesn't check that the domain is not running. it's a bug, but of limited consequence, basically that function is used to allocate the array for the subsequent virConnectListDefinedDomains() call in most scenario i can think of and a slightly too big array is not a problem in practice (and why this was never detected :-) . Fixing it would require xenXMNumOfDefinedDomains() to check for each of them it's not running, which means calling xend which we know is fairly expensive. Maybe this should be fixed, maybe this is not worth it. The XM stuff is really RHEL/Xen specific ... Fixing the comments makes perfect sense, I fixed as * Provides the number of defined but inactive domains. and * list the defined but inactive domains, stores ... and will commit this shortly upstream, thanks ! Daniel
This is the intended behaviour of virConnectNumOfDefinedDomains(). You cannot assume that the number of domains counted by virConnectNumOfDefinedDonmains() necccessarily matches the number of domains returned by virConnectListDefinedDomains(). Between the time you call the 2 APIs, new domains may have started and existing domains may have shut down. The value of the NumOfDefinedDomains() API is basically reasonably hint at a size for array needed to call the ListDefinedDomains() API. As such a over-sized value is perfectly legitimate. The XM driver impl delibrately returns a virConnectNumOfDefinedDonmains() value which is sometimes too large, for efficency reasons - filtering out the active domains is expensive, so only done when we actually list them, not when we count them. So if you need to know the actual number of domain names you need to look at the return value for virConnectListDefinedDomains to see how many members of the array it actually filled in. You can not assume all array members are non-NULL. As such there is no bug here.