[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] Problems accessing ESX using libvirt



2010/4/8 Matthew Booth <mbooth redhat com>:
> I was forwarded the following query relating to v2v:
>
> ===
> There are no firewalls between the hosts and the ESX firewall is
> configured to allow all incoming & outgoing connections.
>
> The "virsh -c 'esx://elabhost011.xxx/' list --all" command
> also fails in the same way as the virt-v2v command.
>
> When I run the 'virsh list' command it doesn't prompt for a
> username/password as in the example below.

> If I run tcpdump on the ESX host, when 'virsh list' is run, I see the
> packet arrive from the test box and a reply sent back, only these two
> packets are sent between the hosts:
>
>        09:51:20.205524 bwyhs0020p.xxx.56436 >
> elabhost011.xxx.16514: S 338(0) win 5840 <mss
> 1460,sackOK,timestamp 1214177495 0,nop,wscale 7> (DF)
>        09:51:20.205544 elabhost011.xxx.16514 >
> bwyhs0020p.xxx.56436: R 0:9 win 0 (DF)
>
>
> The problem is there is nothing listening on port 16514 on the ESX host,
> hence the "Connection refused" message.
>
> Should the connection be using the TSL port as opposed to a 'ESX' port?
> ===
>
> The user is using libvirt  0.6.3-20.1.el5_4.
>
> Unfortunately I'm not intimately familiar with how the libvirt ESX
> driver magic works. Can anybody shed any light?
>
> Thanks,

ESX support was added in libvirt 0.7.0. So libvirt 0.6.3 is too old.

Libvirt will give unexpected error messages when you give it URIs that
no driver handles. For example if no local driver claims to handle an
URI the remote driver will try to connect to a libvirtd on the server
and uses TLS (default libvirt port 16514) for that. That's what you
see in the tcpdump there.

Matthias


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]