Open Stack

Hi,

I meet a problem like this recently:

When attaching a volume to an instance, in the xml, the disk is described
as:

[image: Inline image 1]
where the serial number here is the volume uuid in Cinder. While inside the
vm:
in /dev/disk/by-id, there is a link for /vdb with the name of
"virtio"+truncated serial number:

[image: Inline image 2]

and according to
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/2/html/Getting_Started_Guide/ch16s03.html

it seems that we will use this mount the volume.

The truncate seems to be happen in here [1][2] which is 20 digits.

*My question here is: *if two volume have the identical first 20 digits in
their uuids, it seems that the latter attached one will overwrite the first
one's link:
[image: Inline image 3]
(the above graph is snapshot for an volume backed instance, the
virtio-15exxxxx was point to vda before, the by-path seems correct though)

It is rare to have the identical first 20 digits of two uuids, but
possible, so what was the consideration of truncate only 20 digits of the
volume uuid instead of use full 32?

BR,

Kevin Zheng
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180116/2c4037a9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 13550 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180116/2c4037a9/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 46374 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180116/2c4037a9/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 5228 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180116/2c4037a9/attachment-0002.png>