It turns out that xmlParseURI gives an error if asked to parse the string "xen://".
This string arises because after a URI such as "xen://hostname" has been stripped of its server field, it becomes "xen://" on the remote end of the connection, and the failure of xmlParseURI causes the whole connection to fail.
I'm not sure of the best way to fix it. The attached patch is a semi-hack which at least allows xen://hostname to work. It's not a problem for qemu because these URIs should always contain a path. Nor for test for the same reason. Not sure about OpenVZ.
Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
--- src/libvirt.c.old 2007-10-16 11:26:21.000000000 +0100
+++ src/libvirt.c 2007-10-16 11:24:13.000000000 +0100
@@ -405,6 +405,12 @@ do_open (const char *name, int flags)
if (!strcasecmp(name, "xen"))
name = "xen:///";
+ /* Convert xen:// -> xen:/// because xmlParseURI cannot parse the
+ * former. This allows URIs such as xen://localhost to work.
+ */
+ if (STREQ (name, "xen://"))
+ name = "xen:///";
+
if (!initialized)
if (virInitialize() < 0)
return NULL;
@@ -422,6 +428,21 @@ do_open (const char *name, int flags)
goto failed;
}
+#ifdef ENABLE_DEBUG
+ fprintf (stderr,
+ "libvirt: do_open: name \"%s\" to URI components:\n"
+ " scheme %s\n"
+ " opaque %s\n"
+ " authority %s\n"
+ " server %s\n"
+ " user %s\n"
+ " port %d\n"
+ " path %s\n",
+ name,
+ uri->scheme, uri->opaque, uri->authority, uri->server,
+ uri->user, uri->port, uri->path);
+#endif
+
ret->name = strdup (name);
if (!ret->name) {
virLibConnError (ret, VIR_ERR_NO_MEMORY, "allocating conn->name");
smime.p7s
Description: S/MIME Cryptographic Signature
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
