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@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org