On 02/18/2011 02:30 AM, Matthias Bolte wrote:
> Etienne Gosset reported that libvirt fails to connect to his ESX
> server because it failed to parse its malformed host UUID, that
> contains a additional space and lacks one hexdigit in the last
> group:
>
> xxxxxxxx-xxxx-xxxx-xxxx- xxxxxxxxxxx
Could this merely be a case of the host UUID printing with %12llx
instead of %012llx? That is, would it be worth teaching our parser that
if the initial parse fails, then try again by substituting leading
spaces as implicit 0s to see if that makes it valid? Or is that
situation rare enough that the fallback parse is not worth the effort.
>
> Don't treat this as a fatal error, just ignore it.
> ---
> src/esx/esx_driver.c | 9 +++++----
> 1 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/src/esx/esx_driver.c b/src/esx/esx_driver.c
> index 97f3dbe..116ad0f 100644
> --- a/src/esx/esx_driver.c
> +++ b/src/esx/esx_driver.c
> @@ -518,10 +518,11 @@ esxLookupHostSystemBiosUuid(esxPrivate *priv, unsigned char *uuid)
>
> if (strlen(dynamicProperty->val->string) > 0) {
> if (virUUIDParse(dynamicProperty->val->string, uuid) < 0) {
> - ESX_ERROR(VIR_ERR_INTERNAL_ERROR,
> - _("Could not parse UUID from string '%s'"),
> - dynamicProperty->val->string);
> - goto cleanup;
> + VIR_WARN("Could not parse host UUID from string '%s'",
> + dynamicProperty->val->string);
> +
> + /* HostSystem has an invalid UUID, ignore it */
> + memset(uuid, 0, VIR_UUID_BUFLEN);
At any rate, ACK to this patch, whether or not we try to teach uuid
parsing to be more tolerant of buggy UUIDs like this.
--
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