4:13 p.m.
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
3:59 a.m.
2010/2/9 antonela_other(a)yahoo.com <antonela(a)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
1:37 p.m.
Thank you Matthias.
I addressed the issues that you mentioned below.
Now i have my libvirt built for esx.
I followed the instructions http://libvirt.org/remote.html#Remote_TLS_CA to generate the
CA key/cert and client key/cert.
However, the connect still fails, with "error: internal error curl_easy_perform()
returned an error: Peer certificate cannot be authenticated with known CA certificates
(60)".
Trace is below:
root # virsh -c esx://a.b.c.d
14:21:29.771: debug : virInitialize:336 : register drivers
14:21:29.772: debug : virRegisterDriver:837 : registering Test as driver 0
14:21:29.772: debug : virRegisterNetworkDriver:675 : registering Test as network driver 0
14:21:29.772: debug : virRegisterInterfaceDriver:706 : registering Test as interface
driver 0
14:21:29.772: debug : virRegisterStorageDriver:737 : registering Test as storage driver 0
14:21:29.772: debug : virRegisterDeviceMonitor:768 : registering Test as device driver 0
14:21:29.772: debug : virRegisterSecretDriver:799 : registering Test as secret driver 0
14:21:29.773: debug : virRegisterDriver:837 : registering Xen as driver 1
14:21:29.773: debug : virRegisterDriver:837 : registering OPENVZ as driver 2
14:21:29.774: debug : vboxRegister:109 : VBoxCGlueInit failed, using dummy driver
14:21:29.774: debug : virRegisterDriver:837 : registering VBOX as driver 3
14:21:29.774: debug : virRegisterNetworkDriver:675 : registering VBOX as network driver 1
14:21:29.774: debug : virRegisterStorageDriver:737 : registering VBOX as storage driver 1
14:21:29.774: debug : virRegisterDriver:837 : registering ESX as driver 4
14:21:29.775: debug : virRegisterDriver:837 : registering remote as driver 5
14:21:29.775: debug : virRegisterNetworkDriver:675 : registering remote as network driver
2
14:21:29.775: debug : virRegisterInterfaceDriver:706 : registering remote as interface
driver 1
14:21:29.775: debug : virRegisterStorageDriver:737 : registering remote as storage driver
2
14:21:29.775: debug : virRegisterDeviceMonitor:768 : registering remote as device driver 1
14:21:29.775: debug : virRegisterSecretDriver:799 : registering remote as secret driver 1
14:21:29.775: debug : virConnectOpenAuth:1337 : name=esx://a.b.c.d, auth=0xb7f41678,
flags=0
14:21:29.776: debug : do_open:1106 : name "esx://a.b.c.d" to URI components:
scheme esx
opaque (null)
authority (null)
server a.b.c.d
user (null)
port 0
path (null)
14:21:29.776: debug : do_open:1116 : trying driver 0 (Test) ...
14:21:29.776: debug : do_open:1122 : driver 0 Test returned DECLINED
14:21:29.776: debug : do_open:1116 : trying driver 1 (Xen) ...
14:21:29.776: debug : do_open:1122 : driver 1 Xen returned DECLINED
14:21:29.776: debug : do_open:1116 : trying driver 2 (OPENVZ) ...
14:21:29.776: debug : do_open:1122 : driver 2 OPENVZ returned DECLINED
14:21:29.777: debug : do_open:1116 : trying driver 3 (VBOX) ...
14:21:29.777: debug : do_open:1122 : driver 3 VBOX returned DECLINED
14:21:29.777: debug : do_open:1116 : trying driver 4 (ESX) ...
Enter username for a.b.c.d [root]:
Enter root password for a.b.c.d:
14:21:33.416: debug : do_open:1122 : driver 4 ESX returned ERROR
14:21:33.416: debug : virUnrefConnect:259 : unref connection 0x931f698 1
14:21:33.417: debug : virReleaseConnect:216 : release connection 0x931f698
error: internal error curl_easy_perform() returned an error: Peer certificate cannot be
authenticated with known CA certificates (60)
error: failed to connect to the hypervisor
BTW, I observed that any modification to the /etc/libvirt/libvirt.conf does not take
effect when. Isn't this the default conf file for libvirt/virsh? The changes i am
talking about are:
- for default path for the CA key/cert and clinet key/cert
- uncommented #tls_no_verify_certificate = 1
# ls /etc/pki/CA/
cacert.pem cakey.pem
# ls /etc/pki/libvirt/
clientcert.pem private
# ls /etc/pki/libvirt/private/
clientkey.pem
Thank you in advance for any comments/suggestions.
Antonela
----- Original Message -----
From: "Matthias Bolte" <matthias.bolte(a)googlemail.com>
To: "antonela_other(a)yahoo.com" <antonela(a)comcast.net>
Cc: libvirt-users(a)redhat.com
Sent: Wednesday, February 10, 2010 4:59:18 AM GMT -05:00 US/Canada Eastern
Subject: Re: [libvirt-users] error: unable to connect to libvirtd at 'a.b.c.d':
Connection refused
2010/2/9 antonela_other(a)yahoo.com <antonela(a)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
6:17 p.m.
2010/2/11 antonela_other(a)yahoo.com <antonela(a)comcast.net>:
Thank you Matthias.
I addressed the issues that you mentioned below.
Now i have my libvirt built for esx.
I followed the instructions http://libvirt.org/remote.html#Remote_TLS_CA to
generate the CA key/cert and client key/cert.
However, the connect still fails, with "error: internal error
curl_easy_perform() returned an error: Peer certificate cannot be
authenticated with known CA certificates (60)".
This has nothing to to with the libvirtd certificates. The ESX
support doesn't involve libvirtd.
This error should tell you that libcurl can't verify the ESX server
side SSL certificate used for HTTPS. The simple solution is to disable
the server certificate verification
virsh -c esx://a.b.c.d/?no_verify=1
See http://www.redhat.com/archives/libvir-list/2009-December/msg00757.html
for some details. I'll add a FAQ section to
http://www.libvirt.org/drvesx.html about this basic connection issues,
because several people seem to hit this problems when trying to use
libvirt with ESX.
Matthias
5397
days inactive
5400
days old
3 comments
2 participants
participants (2)
-
antonela_other＠yahoo.com -
Matthias Bolte