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.