[Libvir] remote access ?
I was looking through some of the remote code.. I was wondering if a 32-bit virsh client is supposed to be able to connect to a 64-bit libvirtd? The reason I ask is because I saw some references to longs.. For example, in xdr_remote_node_get_info_ret() ... objp->cpus = IXDR_GET_LONG(buf); objp->mhz = IXDR_GET_LONG(buf); objp->nodes = IXDR_GET_LONG(buf); objp->sockets = IXDR_GET_LONG(buf); objp->cores = IXDR_GET_LONG(buf); objp->threads = IXDR_GET_LONG(buf); Thanks, MRJ
On Thu, Oct 04, 2007 at 12:27:38PM -0400, Mark Johnson wrote:
I was looking through some of the remote code.. I was wondering if a 32-bit virsh client is supposed to be able to connect to a 64-bit libvirtd?
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 ? Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
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.
I'll have to go back and check which one I was compiling at the time.. Maybe it uses that for 32-bit only which should't be a problem...
Are you actually seeing failures when doing 32 -> 64 remote connections or vica-verca ?
I'm not that far yet :-) Just getting those bits to compile now... Thanks, MRJ
On Thu, Oct 04, 2007 at 12:43:53PM -0400, Mark Johnson wrote:
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.
I'll have to go back and check which one I was compiling at the time.. Maybe it uses that for 32-bit only which should't be a problem...
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. Dan -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On 10/4/07, Daniel P. Berrange <berrange@redhat.com> wrote:
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.
Haven't gotten to that part yet.. :-) Right now, I'm trying to do a simple tcp connect on my fedora 7 box to my fedora 7 box (with 0.3.2). I'm not sure why the following is not working? Anyone know what I'm doing wrong? [root@fedora ~]# cat /etc/libvirt/libvirtd.conf listen_tcp=1 tcp_port="16509" root@fedora ~]# /etc/init.d/libvirtd stop Stopping libvirtd daemon: [ OK ] [root@fedora ~]# /etc/init.d/libvirtd start Starting libvirtd daemon: [ OK ] [root@fedora ~]# virsh connect xen+tcp://localhost libvir: Remote error : Connection refused error: Failed to connect to the hypervisor [root@fedora ~]# virsh list --all Id Name State ---------------------------------- 0 Domain-0 running - solaris shut off
On Thu, Oct 04, 2007 at 04:36:35PM -0400, Mark Johnson wrote:
On 10/4/07, Daniel P. Berrange <berrange@redhat.com> wrote:
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.
Haven't gotten to that part yet.. :-)
Right now, I'm trying to do a simple tcp connect on my fedora 7 box to my fedora 7 box (with 0.3.2). I'm not sure why the following is not working? Anyone know what I'm doing wrong?
The config file merely controls whether todo TCP or TLS, to actually enable listening for connection you need to edit /etc/sysconfig/libvirtd and then restart the daemon Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
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 ...) 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
On 10/15/07, Richard W.M. Jones <rjones@redhat.com> 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/ Thanks, MRJ
On Mon, Oct 15, 2007 at 09:26:26AM -0400, Mark Johnson wrote:
On 10/15/07, Richard W.M. Jones <rjones@redhat.com> 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 ... Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Mon, Oct 15, 2007 at 10:40:21AM -0400, 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@redhat.com> 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 ...
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. The check for a plain 'xen' is also now redundant, since src/libvirt.c turns that into a well-formed URI before it gets passed into the Xen driver: /* Convert NULL or "" to xen:/// for back compat */ if (!name || name[0] == '\0') name = "xen:///"; /* Convert xen -> xen:/// for back compat */ if (!strcasecmp(name, "xen")) name = "xen:///"; Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
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. 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
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. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
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. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel Veillard wrote:
On Mon, Oct 15, 2007 at 08:33:08PM +0100, Daniel P. Berrange 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
On Mon, Oct 15, 2007 at 04:37:22PM +0100, Richard W.M. Jones wrote: 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). 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
On Tue, Oct 16, 2007 at 07:18:13AM +0100, Richard W.M. Jones wrote:
Daniel Veillard wrote:
On Mon, Oct 15, 2007 at 08:33:08PM +0100, Daniel P. Berrange 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
On Mon, Oct 15, 2007 at 04:37:22PM +0100, Richard W.M. Jones wrote: 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).
oh, right, of course ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
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@redhat.com> 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). 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
Richard W.M. Jones wrote:
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@redhat.com> 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).
(Ignore this ...) 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
On Thu, Oct 04, 2007 at 05:34:04PM +0100, Daniel P. Berrange wrote:
On Thu, Oct 04, 2007 at 12:27:38PM -0400, Mark Johnson wrote:
I was looking through some of the remote code.. I was wondering if a 32-bit virsh client is supposed to be able to connect to a 64-bit libvirtd?
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 ?
FYI, I completely forgot, but I am actually using 32- > 64 on a regular basis. My laptop is 32-bit and I'm using virt-manager to remotely access 64-bit hosts using both SSH + TLS data transports Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
participants (4)
-
Daniel P. Berrange -
Daniel Veillard -
Mark Johnson -
Richard W.M. Jones