Re: [libvirt] [PATCH] esx: Use MD5 sum of mount path as storage pool UUID
2010/8/9 Justin Clift <jclift(a)redhat.com>:
On 08/09/2010 06:56 AM, Matthias Bolte wrote:
>
> With the previous storage pool UUID source not all storage pools
> had a proper UUID, especially GSX storage pools. The mount path
> is unique per host and cannot change during the lifetime of the
> datastore. Therefore, its MD5 sum can be used as UUID.
>
> Use gnulib's crypto/md5 module to generate the MD5 sum.
Just as a general thought, would it be preferably to use the SHA1 function
instead of the MD5 one?
Every non-trivial hash function will do for the purpose of deriving a
UUID from the mount path.
Asking because MD5 seems to be trending "out of favour" (as
a
generalisation) compared to SHA1, after some cryptographers showed MD5 hash
collisions could be practically achieved with some types of data. (or
something along those lines)
I'm aware of MD5 being considered as broken for cryptographic use
cases, but this one isn't cryptographic so I don't care about the
problem of crafted collisions here. The only real problem here would
be when you have two datastores with different mount paths that hash
to the same UUID, but I think md5 is collision-free enough so we can
ignore this problem.
There is another "problem" with the approach of using the mount path
hash as UUID. In case of a Windows based GSX server you can use CIFS
shares as datastores addressed via UNC paths like \\nas\share. If you
have multiple GSX server sharing that datastore then all will have the
same UUID because the have the same mount path. Actually I don't
consider this as a real problem because in this case there is one
datastore with one UUID shared between multiple hosts.
For all intents and purposes, I'm thinking it'll make no
practical
functional difference, but figure it's worth asking. :)
gnulib also provides SHA1 and SHA256 so we could use those instead of
MD5, but I think MD5 is good enough for this special use case here.
Matthias