Yes. The wire protocol is 32/64 invariant. > The reason I ask is because I saw some references to longs.. > For example, in xdr_remote_node_get_info_ret() I must admit to being puzzelled as to why rpcgen decided to use IXDR_GET_LONG there. All the rest of the code in that function is using int, and the protocol is defined to be int.

Are you actually seeing failures when doing 32 -> 64 remote connections or vica-verca ?

The remote_protocol.c/h files are generated from remote_protocol.x using rpcgen. That said, we actually distribute the generated files and keep them in CVS, since the protocol doesn't change & we prefer to have known tested code, rather than whatever rpcgen decides to generate per OS. If you do see problems it could of course be a bug in the rpcgen tool we used, so may be worth deleting the .c/h files and seeing if the Solaris rpcgen does a better job.

[root@fedora ~]# virsh connect xen+tcp://localhost libvir: Remote error : Connection refused error: Failed to connect to the hypervisor

On 10/15/07, Richard W.M. Jones <rjones(a)redhat.com&gt; wrote: > Mark Johnson wrote: > > [root@fedora ~]# virsh connect xen+tcp://localhost > > libvir: Remote error : Connection refused > > error: Failed to connect to the hypervisor > > IME this usually happens because I forget to open the right port on the > firewall (both incoming and outgoing ...) Thanks Rich. My problem was I typed the line wrong. It needed a trailing / e.g. > [root@fedora ~]# virsh connect xen+tcp://localhost Should have been... [root@fedora ~]# virsh connect xen+tcp://localhost/

It is a bug in xend_internal.c if (strcasecmp (name, "xen") == 0 || strncasecmp (name, "xen:///", 7) == 0) { This needs to die & be replaced with code calling the libxml URI parsing. I fixed a similar bug in the QEMU driver a few weeks back.

On Mon, Oct 15, 2007 at 04:37:22PM +0100, Richard W.M. Jones wrote: > Daniel P. Berrange wrote: > >It is a bug in xend_internal.c > > > > if (strcasecmp (name, "xen") == 0 || > > strncasecmp (name, "xen:///", 7) == 0) { > > > > > >This needs to die & be replaced with code calling the libxml URI parsing. > >I fixed a similar bug in the QEMU driver a few weeks back. > > Sorry yes, Dan is right, so ignore the hack/patch I just posted. > > In fact xen_unified.c already parses the URI once, so we just need to > change the xen_unified <-> xen low level drivers API to pass the parsed > URI instead of the name string. In fact we could take it one bit further. Have the 'do_open' method in the src/libvirt.c file parse it & change the src/driver.h so that the open method for drivers takes xmlURIPtr instead of a char *. That way we guarentee that all drivers will use a correctly parsed form.

Daniel Veillard wrote: >On Mon, Oct 15, 2007 at 08:33:08PM +0100, Daniel P. Berrange wrote: >>On Mon, Oct 15, 2007 at 04:37:22PM +0100, Richard W.M. Jones wrote: >>>Daniel P. Berrange wrote: >>>>It is a bug in xend_internal.c >>>> >>>> if (strcasecmp (name, "xen") == 0 || >>>> strncasecmp (name, "xen:///", 7) == 0) { >>>> >>>> >>>>This needs to die & be replaced with code calling the libxml URI >>>>parsing. >>>>I fixed a similar bug in the QEMU driver a few weeks back. >>>Sorry yes, Dan is right, so ignore the hack/patch I just posted. >>> >>>In fact xen_unified.c already parses the URI once, so we just need to >>>change the xen_unified <-> xen low level drivers API to pass the parsed >>>URI instead of the name string. >>In fact we could take it one bit further. Have the 'do_open' method in >>the src/libvirt.c file parse it & change the src/driver.h so that the >>open method for drivers takes xmlURIPtr instead of a char *. That way >>we guarentee that all drivers will use a correctly parsed form. > > Sounds good but we would have to reserialize for the network access >I assume. Yes, it already does this because it has to reconstruct a URI suitable for the remote end of the connection. Specifically one which doesn't contain the transport, server and port. (Otherwise the remote end might try to do another remote connection, which wouldn't be fun).

Daniel Veillard wrote: > On Mon, Oct 15, 2007 at 09:26:26AM -0400, Mark Johnson wrote: >> On 10/15/07, Richard W.M. Jones <rjones(a)redhat.com&gt; wrote: >>> Mark Johnson wrote: >>>> [root@fedora ~]# virsh connect xen+tcp://localhost >>>> libvir: Remote error : Connection refused >>>> error: Failed to connect to the hypervisor >>> IME this usually happens because I forget to open the right port on the >>> firewall (both incoming and outgoing ...) >> Thanks Rich. My problem was I typed the line wrong. It needed >> a trailing / >> >> e.g. >> >>> [root@fedora ~]# virsh connect xen+tcp://localhost >> Should have been... >> [root@fedora ~]# virsh connect xen+tcp://localhost/ > > Hum, strange, that's still a valid absolute URI except with an empty > path I find strange we have a problem with this, as we don't use the > path for the access in practice ... The attached patch is "a bit of a hack" (but so is the current code).