Re: [libvirt] Problems accessing ESX using libvirt
Given the latest version of libvirt available for RHEL 5 is libvirt-0.6.3-33, what is the
recommended download site for libvirt-0.7.0?
Obviously I can get a copy off of brew, but what dependency issues might I run into and is
it possible for the customer to get simply leverage a libvirt from Fedora?
Regards,
----------
Eric L. Sammons, RHCE
Red Hat, Inc.
Technical Account Manager
Office: 919.754.4963 | Cell: 919.802.0239
----- Original Message -----
From: "Matthias Bolte" <matthias.bolte(a)googlemail.com>
To: "Matthew Booth" <mbooth(a)redhat.com>
Cc: libvir-list(a)redhat.com, "Eric Sammons" <esammons(a)redhat.com>
Sent: Thursday, April 8, 2010 11:37:05 AM GMT -05:00 US/Canada Eastern
Subject: Re: [libvirt] Problems accessing ESX using libvirt
2010/4/8 Matthew Booth <mbooth(a)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