libvirt users - Feb 2010 - error: unable to connect to libvirtd at 'a.b.c.d': Connection refused

Greetings: 





I have an issue with connecting to the esx hypervisor from my guest Vm. The
purpose of the connection is to obtain host related information (like network,
devices etc).



I am not sure what is it that rejects the connect at the server side, and what i
am missing.

I am running lib0.7.5, i have libvirtd running on guest-vm. 

The host ESX has the ip address a.b.c.d. 



? 

Any thoughts? 





? 



Below the error with some debug output from libvirt. 







root > virsh -c esx://a.b.c.d/system 





?...................... 

17:06:16.065: debug : virConnectOpenAuth:1337 : name=esx://10.59.56.109/system,
auth=0xb80ac638, flags=0



17:06:16.065: debug : do_open:1106 : name "esx://10.59.56.109/system"
to URI components:



? scheme esx 



? opaque (null) 



? authority (null) 



? server 10.59.56.109 



? user (null) 



? port 0 



? path /system 





? 

17:06:16.065: debug : do_open:1116 : trying driver 0 (Test) ... 



17:06:16.066: debug : do_open:1122 : driver 0 Test returned DECLINED 



17:06:16.066: debug : do_open:1116 : trying driver 1 (Xen) ... 



17:06:16.066: debug : do_open:1122 : driver 1 Xen returned DECLINED 



17:06:16.066: debug : do_open:1116 : trying driver 2 (OPENVZ) ... 



17:06:16.066: debug : do_open:1122 : driver 2 OPENVZ returned DECLINED 



17:06:16.066: debug : do_open:1116 : trying driver 3 (VBOX) ... 



17:06:16.066: debug : do_open:1122 : driver 3 VBOX returned DECLINED 



17:06:16.066: debug : do_open:1116 : trying driver 4 (remote) ... 



17:06:16.067: debug : doRemoteOpen:564 : proceeding with name = esx:///system 



17:06:16.069: debug : initialise_gnutls:1145 : loading CA file
/etc/pki/CA/cacert.pem



17:06:16.070: debug : initialise_gnutls:1158 : loading client cert and key from
files /etc/pki/libvirt/clientcert.pem and /etc/pki/libvirt/private/clientkey.pem



17:06:16.074: debug : do_open:1122 : driver 4 remote returned ERROR 



17:06:16.074: debug : virUnrefConnect:259 : unref connection 0x903e078 1 



17:06:16.074: debug : virReleaseConnect:216 : release connection 0x903e078 



error: unable to connect to libvirtd at a.b.c.d': Connection refused 



error: failed to connect to the hypervisor 







I tried to use uri like: esx://a.b.c.d/, esx://a.b.c.d, esxi://a.b.c.d/system
etc. They all give same issue.



Thanks. 



? 

Antonela 





?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://listman.redhat.com/archives/libvirt-users/attachments/20100209/9be96f1c/attachment.htm>

2010/2/9 antonela_other at yahoo.com <antonela at
comcast.net>:
> Greetings:
>
Hello.
>
> I have an issue with connecting to the esx hypervisor from my guest Vm. The
> purpose of the connection is to obtain host related information (like
> network, devices etc).
>
Unfortunately network and device enumeration is not implemented yet
for the ESX driver.
>
> I am not sure what is it that rejects the connect at the server side, and
> what i am missing.
>
> I am running lib0.7.5, i have libvirtd running on guest-vm.
ESX support was added in 0.7.0, so your libvirt version is new enough.
For ESX you don't need an libvirtd, neither on the client side nor on
the server side, see http://libvirt.org/drvesx.html#prereq
> The host ESX has the ip address a.b.c.d.
>
>
>
> Any thoughts?
>
Are you sure that your libvirt was build with ESX support enabled? If
you're using the Debian/Ubuntu packages that could be your problem,
because they are build without ESX support. So you'll either need to
file a bugreport with Debian/Ubuntu about the excluded ESX support, or
build libvirt from source. If you're already building from source make
sure to install the libcurl development package version 7.18.0 or
newer, otherwise configure will disable ESX support.
>
> Below the error with some debug output from libvirt.
>
>
>
> root > virsh -c esx://a.b.c.d/system
>
> ?......................
>
> 17:06:16.065: debug : virConnectOpenAuth:1337 :
> name=esx://10.59.56.109/system, auth=0xb80ac638, flags=0
>
> 17:06:16.065: debug : do_open:1106 : name
"esx://10.59.56.109/system" to URI
> components:
>
> ? scheme esx
>
> ? opaque (null)
>
> ? authority (null)
>
> ? server 10.59.56.109
>
> ? user (null)
>
> ? port 0
>
> ? path /system
>
>
>
> 17:06:16.065: debug : do_open:1116 : trying driver 0 (Test) ...
>
> 17:06:16.066: debug : do_open:1122 : driver 0 Test returned DECLINED
>
> 17:06:16.066: debug : do_open:1116 : trying driver 1 (Xen) ...
>
> 17:06:16.066: debug : do_open:1122 : driver 1 Xen returned DECLINED
>
> 17:06:16.066: debug : do_open:1116 : trying driver 2 (OPENVZ) ...
>
> 17:06:16.066: debug : do_open:1122 : driver 2 OPENVZ returned DECLINED
>
> 17:06:16.066: debug : do_open:1116 : trying driver 3 (VBOX) ...
>
> 17:06:16.066: debug : do_open:1122 : driver 3 VBOX returned DECLINED
Yep, your libvirt is build without ESX support. If it is enabled it
would be probed before the remote driver.
> 17:06:16.066: debug : do_open:1116 : trying driver 4 (remote) ...
>
> 17:06:16.067: debug : doRemoteOpen:564 : proceeding with name >
esx:///system
>
> 17:06:16.069: debug : initialise_gnutls:1145 : loading CA file
> /etc/pki/CA/cacert.pem
>
> 17:06:16.070: debug : initialise_gnutls:1158 : loading client cert and key
> from files /etc/pki/libvirt/clientcert.pem and
> /etc/pki/libvirt/private/clientkey.pem
>
> 17:06:16.074: debug : do_open:1122 : driver 4 remote returned ERROR
>
> 17:06:16.074: debug : virUnrefConnect:259 : unref connection 0x903e078 1
>
> 17:06:16.074: debug : virReleaseConnect:216 : release connection 0x903e078
>
> error: unable to connect to libvirtd at a.b.c.d': Connection refused
The error message could be more explicit about the missing ESX
support, I'll try to improve this.
> error: failed to connect to the hypervisor
>
>
>
>
>
> I tried to use uri like: esx://a.b.c.d/, esx://a.b.c.d,
> esxi://a.b.c.d/system etc. They all give same issue.
>
See http://libvirt.org/drvesx.html#uri for the URI format understood
by the ESX driver, there is no distinction between /system and
/session as with some other drivers.

Matthias