Bug 437216

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.