[libvirt] [PATCH] esx: Ignore malformed host UUID from BIOS

[Daniel P. Berrange]

On Fri, Feb 18, 2011 at 06:17:15PM +0100, Matthias Bolte wrote:
> 2011/2/18 Eric Blake <eblake at 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.

The UUIDs you get out of the BIOS via dmidecode are frequently
complete & utter junk. I seen "UUIDs" like

 "TO BE FILLED BY THE OEM"
 "00000000000000000000000"
 "11111-1111-1111-1111-1111"

and to my horror last week I discovered that two of my
machines were actually shipped with identical UUIDs!

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|