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@xxxxxxxxxx +1-801-349-2682
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list