On Fri, Feb 18, 2011 at 06:17:15PM +0100, Matthias Bolte wrote: > 2011/2/18 Eric Blake <eblake@xxxxxxxxxx>: > > 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list