Open Stack

Hi,

This seems to be a QEMU limitation, the 20 character limit being enforced here: https://github.com/qemu/qemu/blob/v2.11.0/hw/scsi/scsi-disk.c#L645

We do have an alternative approach for safely identifying disks. When using Hyper-V, we cannot change the disk serial id that gets exposed to the guest. For this reason, we're always providing the disk SCSI address through the nova instance metadata, which already gets used by kubernetes[1]. Note that the Nova libvirt driver only provides it when a volume tag is set [2].

[1] https://github.com/kubernetes/kubernetes/blob/53a8ac753bf468eaf6bcb5a07e34a0a67480df43/pkg/cloudprovider/providers/openstack/openstack_volumes.go#L485
[2] https://github.com/openstack/nova/blob/17.0.0.0b2/nova/virt/libvirt/driver.py#L7956-L7969

Regards,
Lucian Petrut (lpetrut)

On Tue, 2018-01-16 at 17:19 +0800, Yikun Jiang wrote:
Some detail steps as below:
1. First, We have 2 volumes with same part-uuid prefix.
[内嵌图片 1]

volume(yikun2) is attached to server(test)

2. In GuestOS(Cent OS 7), take a look at by path and by id:
[内嵌图片 2]
we found both by-path and by-id vdb links was generated successfully.

3. attach volume(yikun2_1) to server(test)
[内嵌图片 4]

4. In GuestOS(Cent OS 7), take a look at by path and by id:

[内嵌图片 6]

by-path soft link was generated successfully, but by-id link was failed to generate.
That is, in this case, if a user find the device by by-id, it would be failed to find it or find a wrong device.

one of the user cases was happened on k8s device finding, more info you can see the ref as below:
https://github.com/kubernetes/kubernetes/blob/53a8ac753bf468eaf6bcb5a07e34a0a67480df43/pkg/cloudprovider/providers/openstack/openstack_volumes.go#L463

So, I think by-id is NOT a good way to find the device, but what the best practice is? let's see other idea.

Regards,
Yikun

----------------------------------------
Jiang Yikun（Kero）
Mail: yikunkero at gmail.com<mailto:yikunkero at gmail.com>

2018-01-16 14:36 GMT+08:00 Zhenyu Zheng <zhengzhenyulixi at gmail.com<mailto:zhengzhenyulixi at gmail.com>>:
Ops, forgot references:
[1] https://github.com/torvalds/linux/blob/1cc15701cd89b0ce695bbc5cff3a2bf3e2efd25f/include/uapi/linux/virtio_blk.h#L54
[2] https://github.com/torvalds/linux/blob/1cc15701cd89b0ce695bbc5cff3a2bf3e2efd25f/drivers/block/virtio_blk.c#L363

On Tue, Jan 16, 2018 at 2:35 PM, Zhenyu Zheng <zhengzhenyulixi at gmail.com<mailto:zhengzhenyulixi at gmail.com>> wrote:
Hi,

I meet a problem like this recently:

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

[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:

[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:
[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



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org<mailto:OpenStack-dev-request at lists.openstack.org>?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180116/588b0c9a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 46374 bytes
Desc: image.png
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180116/588b0c9a/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 5228 bytes
Desc: image.png
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180116/588b0c9a/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 13550 bytes
Desc: image.png
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180116/588b0c9a/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 21095 bytes
Desc: image.png
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180116/588b0c9a/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 9638 bytes
Desc: image.png
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180116/588b0c9a/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 19561 bytes
Desc: image.png
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180116/588b0c9a/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 10798 bytes
Desc: image.png
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180116/588b0c9a/attachment-0006.png>