2011/2/18 Eric Blake <eblake@redhat.com>:
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.
Interesting idea, but I think %12llx vs %012llx is not the problem here, as I have an ESX server here that has a host UUID with leading zeros in the last group. The actual question I have left is who broke the UUID. Is it already malformed in the BIOS, or does the ESX server mess it up? I just found out that dmidecode is available in the service console so I can ask Etienne to lookup the UUID directly.
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.
Thanks, pushed. Matthias