On 06/09/2010 05:28 PM, Matthias Bolte wrote:
Report that libvirt was built without that driver instead of
trying to connect to a libvirtd, when we know that this is
going to fail.
---
I had this on my todo list for a while now, because multiple people on
the mailing list and on IRC reported problems that can be summarized as:
"I just built/installed libvirt and want to connect to an ESX server,
but libvirt complains about missing certificates or wants to connect to
a non-existing libvirtd on the ESX server. I don't get it..."
The problem was always the same: libvirt built without the ESX driver.
But people don't get that, because libvirt reported cryptic errors in
that situation.
Seems reasonable.
for (i = 0; i < virDriverTabCount; i++) {
+ /* We're going to probe the remote driver next. So we have already
+ * probed all other client-side-only driver before, but none of them
+ * accepted the URI.
+ * If the scheme corresponds to a known but disabled client-side-only
+ * driver then report a useful error, instead of a cryptic one about
+ * not being able to connect to libvirtd or not being able to find
+ * certificates. */
Thanks for the comment; it helps. My only worry is whether there is a
maintenance burden on deciding which drivers are client-side-only, and
whether we will remember to add future drivers here or to remove
existing members of this list at a point when we add remote support for
these drivers, but I don't think it is too bad.
ACK.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org