On Thu, Aug 12, 2010 at 01:40:14AM +0200, Matthias Bolte wrote: > 2010/8/9 Justin Clift <jcl...@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.
This is actually a feature! If the same storage pool is visible on multiple hosts, it is absolutely desirable that it have the same UUID on each host. > > 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. Agreed, we don't need cryptographic security for this use case, so MD5 is fine. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
