Brilliant! I was not building with ESX support.
2010/3/4 Jonathan Kelley <jkelley@vm-labs.com>:
> I must be missing something here so I don't need to install anything butYour libxml2 version expects a / before the query parameters. you
> using esx requires what looks like TLS configured along with libvirtd
> running on ESX.
> When I do esx:// I get the following:
> 14:07:44.736: debug : virConnectOpenAuth:1355 : name=esx://test?no_verify=1,
> auth=0x7f4512a6e5a0, flags=0
> 14:07:44.736: debug : do_open:1110 : name "esx://test?no_verify=1" to URI
> components:
> scheme esx
> opaque (null)
> authority (null)
> server test
> user (null)
> port 0
> path ?no_verify=1
should use esx://test/?no_verify=1 as URI.
Here libvirt should probe the ESX driver, but it doesn't, and because
> 14:07:44.736: debug : do_open:1120 : trying driver 0 (Test) ...
> 14:07:44.736: debug : do_open:1126 : driver 0 Test returned DECLINED
> 14:07:44.736: debug : do_open:1120 : trying driver 1 (OPENVZ) ...
> 14:07:44.736: debug : do_open:1126 : driver 1 OPENVZ returned DECLINED
> 14:07:44.736: debug : do_open:1120 : trying driver 2 (VBOX) ...
> 14:07:44.736: debug : do_open:1126 : driver 2 VBOX returned DECLINED
no driver accepted the URI until here libvirt probes the remote
driver. The remote driver then tries to connect to a libvirtd on the
ESX server but fails.
Sorry, I should have spotted this problem in your previous mail.
The problems here is that your libvirt doesn't have ESX support
> 14:07:44.736: debug : do_open:1120 : trying driver 3 (remote) ...
> 14:07:44.736: debug : doRemoteOpen:564 : proceeding with name =
> esx://%3Fno_verify=1
> 14:07:44.737: debug : initialise_gnutls:1143 : loading CA file
> /apps/etc/pki/CA/cacert.pem
> 14:07:44.737: debug : initialise_gnutls:1156 : loading client cert and key
> from files /apps/etc/pki/libvirt/clientcert.pem and
> /apps/etc/pki/libvirt/private/clientkey.pem
> 14:07:44.739: error : doRemoteOpen:644 : unable to connect to libvirtd at
> 'test': Connection refused
> 14:07:44.739: debug : do_open:1126 : driver 3 remote returned ERROR
> 14:07:44.739: debug : virUnrefConnect:259 : unref connection 0x1f3bd10 1
> 14:07:44.739: debug : virReleaseConnect:216 : release connection 0x1f3bd10
> -Jon
enabled. The ESX driver requires libcurl 7.18.0 or newer. The
configure script tests if libcurl is available and disables ESX
support if it's missing. Check the summary at the end of the configure
script output and make sure it says 'ESX: yes'.
The libvirt error reporting in the case of known but disabled drivers
is not so useful. You're not the first one that struggles with this
problem. I've a half finished patch lying around that addresses this
problem and improves the error reporting in this situation.
Matthias
> On Thu, Mar 4, 2010 at 1:54 PM, Matthias Bolte
> <matthias.bolte@googlemail.com> wrote:
>>
>> Ah, don't use esx+ssh://, just use esx://
>>
>> The scheme format <driver>+<transport>:// implies that you want to use
>> the libvirt remote mechanisms via the libvirt daemon (libvirtd) or the
>> server side, but the ESX driver doesn't use this. It directly connects
>> to the ESX server using HTTPS.
>>
>> You do not need to have or install netcat on the ESX server, as said
>> before an out-of-the-box ESX installation is sufficient.
>>
>> Matthias
>>
>> 2010/3/4 Jonathan Kelley <jkelley@vm-labs.com>:
>> > I built it from the 0.7.6 sources but it still shows me that it is
>> > running
>> > the 'nc' command on the ESX server (which does not exist). Is netcat
>> > required to be on ESX?
>> >
>> > 13:24:26.765: debug : do_open:1110 : name "esx+ssh://test" to URI
>> > components:
>> > scheme esx+ssh
>> > opaque (null)
>> > authority (null)
>> > server test
>> > user (null)
>> > port 0
>> > path
>> >
>> > 13:24:26.765: debug : do_open:1120 : trying driver 0 (Test) ...
>> > 13:24:26.765: debug : do_open:1126 : driver 0 Test returned DECLINED
>> > 13:24:26.765: debug : do_open:1120 : trying driver 1 (OPENVZ) ...
>> > 13:24:26.765: debug : do_open:1126 : driver 1 OPENVZ returned DECLINED
>> > 13:24:26.765: debug : do_open:1120 : trying driver 2 (VBOX) ...
>> > 13:24:26.765: debug : do_open:1126 : driver 2 VBOX returned DECLINED
>> > 13:24:26.765: debug : do_open:1120 : trying driver 3 (remote) ...
>> > 13:24:26.765: debug : doRemoteOpen:564 : proceeding with name = esx://
>> > 13:24:26.765: debug : virExecWithHook:640 : ssh test nc -U
>> > /apps/var/run/libvirt/libvirt-sock
>> > 13:24:26.769: debug : remoteIO:8429 : Do proc=66 serial=0 length=28
>> > wait=(nil)
>> > 13:24:26.769: debug : remoteIO:8491 : We have the buck 66 0x7fc565c4b010
>> > 0x7fc565c4b010
>> > 13:24:31.384: error : remoteIOReadBuffer:7707 : server closed connection
>> > 13:24:31.384: debug : remoteIOEventLoop:8376 : Giving up the buck due to
>> > I/O
>> > error 66 0x7fc565c4b010 (nil)
>> > 13:24:31.384: debug : do_open:1126 : driver 3 remote returned ERROR
>> > 13:24:31.384: debug : virUnrefConnect:259 : unref connection 0x1146d20 1
>> > 13:24:31.384: debug : virReleaseConnect:216 : release connection
>> > 0x1146d20
>> >
>> >
>> > Thanks,
>> > Jon
>> >
>> > On Thu, Mar 4, 2010 at 12:26 PM, Matthias Bolte
>> > <matthias.bolte@googlemail.com> wrote:
>> >> 2010/3/4 Jonathan Kelley <jkelley@vm-labs.com>:
>> >>> Hello,
>> >>>
>> >>> I am trying to access an ESXi host using libvirt but it seems that it
>> >>> requires netcat to be running on the ESX server.
>> >>>
>> >>> My ESX 4 does not have this installed and I am wondering if this is
>> >>> required or is there some other way to get this working?
>> >>>
>> >>> Thanks,
>> >>> Jon
>> >>>
>> >>
>> >> No, you do not have to install anything on the ESX or ESXi server.
>> >> libvirt works with an out-of-the-box installation of ESX.
>> >>
>> >> Make sure your libvirt version is new enough (0.7.0 or newer) and that
>> >> the ESX support is enabled. For example if you've installed libvirt
>> >> from Debian packages then you'll need to build libvirt from source,
>> >> because Debian explicitly disables ESX support in their packages for
>> >> some unknown reason.
>> >>
>> >> See http://libvirt.org/drvesx.html if you haven't yet.
>> >>
>> >> Matthias
>> >>
>> >
>> >
>
>