On Wed, Jul 04, 2007 at 05:12:53AM +0100, Daniel P. Berrange wrote:
On Tue, Jul 03, 2007 at 04:14:30PM +0100, Richard W.M. Jones wrote:
> I'm not quite sure what the problem is (although the problem is in
> xm_internal), but when you use xm_internal over remote, it sometimes
> doesn't initialize its internal cache correctly, so it thinks that
> there are no inactive domains.
>
> The fix is a one-liner which I hit upon by accident -- I don't really
> understand why it works:
Very peculiar - the nconnections stuff is incremented / decremented
by the xenXMOpen & xenXMClose methods. So the change you show below
should be identical to previous behaviour. Is something calling the
xenXMClose method too many times maybe ? I guess some judicious use
of syslog would show it up
Hum, I really dislike the following:
int xenXMClose(virConnectPtr conn ATTRIBUTE_UNUSED) {
if (!nconnections--) {
I don't want to have to rely on C operator priorities to try to guess
if the code is correct.
nconnections--;
if (nconnections <= 0) {
is way cleaner IMHO.
>
> @@ -489,7 +487,7 @@
> xenXMOpen (virConnectPtr conn ATTRIBUTE_UNUSED,
> const char *name ATTRIBUTE_UNUSED, int flags
> ATTRIBUTE_UNUSED)
> {
> - if (nconnections == 0) {
> + if (configCache == NULL) {
> configCache = virHashCreate(50);
> if (!configCache)
> return (-1);
IMHO that patch is wrong because it would not reset nconnections to 0
I would prefer to understand what is really going on. Could you check with
the cleanup of xenXMClose to see if this is sufficient ?
> But the attached patch also adds proper error messages to
> xenXMConfigCacheRefresh too.
That is fine. There is still one thing I don't understand in the original
patch, the replacement of xenDaemonDomainLookupByName() by
xenDaemonLookupByName() which I don't see in the current code ?!?
Daniel
--
Red Hat Virtualization group
http://redhat.com/virtualization/
Daniel Veillard | virtualization library
http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/