2010/3/4 Jonathan Kelley <jkelley(a)vm-labs.com&gt;: > 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

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(a)vm-labs.com&gt;: > 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(a)googlemail.com&gt; wrote: >> 2010/3/4 Jonathan Kelley <jkelley(a)vm-labs.com&gt;: >>> 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 >> > >

2010/3/4 Jonathan Kelley <jkelley(a)vm-labs.com&gt;: > I must be missing something here so I don't need to install anything but > 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 Your libxml2 version expects a / before the query parameters. you should use esx://test/?no_verify=1 as URI. > 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 Here libvirt should probe the ESX driver, but it doesn't, and because 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. > 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 The problems here is that your libvirt doesn't have ESX support 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(a)googlemail.com&gt; 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(a)vm-labs.com&gt;: >> > 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(a)googlemail.com&gt; wrote: >> >> 2010/3/4 Jonathan Kelley <jkelley(a)vm-labs.com&gt;: >> >>> 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 >> >> >> > >> > > >