As of SMBIOS 2.6 (released in 2008), the first three fields of the UUID are well-defined as being encoded in little-endian. Before that, they could be encoded in "network byte order" (i.e. big-endian) if people felt like it.
Presumably enough people did feel like it, as dmidecode specifically has different code paths for pre-2.6 and post-2.6 SMBIOS versions; it will decode pre-2.6 UUIDs as big-endian and post-2.6 UUIDs as little-endian. (The comment in the dmidecode source code at [0] explains this pretty well.)
And, you've guessed it, Azure reports a pre-2.6 version of SMBIOS. (To be precise, 2.3, which was released in _1999_; Azure is old skool cool). This explains the difference between the kernel-reported UUID (always little-endian) and the dmidecode-reported UUID (big-endian on Azure, but little-endian on most modern systems).
OK, so I've done a bit of digging.
As of SMBIOS 2.6 (released in 2008), the first three fields of the UUID are well-defined as being encoded in little-endian. Before that, they could be encoded in "network byte order" (i.e. big-endian) if people felt like it.
Presumably enough people did feel like it, as dmidecode specifically has different code paths for pre-2.6 and post-2.6 SMBIOS versions; it will decode pre-2.6 UUIDs as big-endian and post-2.6 UUIDs as little-endian. (The comment in the dmidecode source code at [0] explains this pretty well.)
And, you've guessed it, Azure reports a pre-2.6 version of SMBIOS. (To be precise, 2.3, which was released in _1999_; Azure is old skool cool). This explains the difference between the kernel-reported UUID (always little-endian) and the dmidecode-reported UUID (big-endian on Azure, but little-endian on most modern systems).
[0] https:/ /github. com/mirror/ dmidecode/ blob/master/ dmidecode. c#L415