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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list