I think this could be related to how things are seen now with the multi-attach feature.
Prior to having multi-attach we stored the "attached_mode" in the volume's metadata (which is presented as the "Properties" column by the OpenStack client.
But now that we have multi-attach we store the "attached_mode" as a specific column in our "volume_attachment" DB table.
So I think that after we do a migration of a volume we may lose that metadata.
Please set use the following command to see the attachments available on the volume:
"cinder --os-volume-api-version=3.27 attachment-list --volume-id=4394bec9-3b87-4a6e-b977-cb56719b0d2a"
And once you have the ID of the attachment, check the details with
"cinder --os-volume-api-version=3.27 attachment-show $ATTACHMENT_UUID"
And see if the right attachment mode is present there.
I think this could be related to how things are seen now with the multi-attach feature.
Prior to having multi-attach we stored the "attached_mode" in the volume's metadata (which is presented as the "Properties" column by the OpenStack client.
But now that we have multi-attach we store the "attached_mode" as a specific column in our "volume_attachment" DB table.
So I think that after we do a migration of a volume we may lose that metadata.
Please set use the following command to see the attachments available on the volume: api-version= 3.27 attachment-list --volume- id=4394bec9- 3b87-4a6e- b977-cb56719b0d 2a"
"cinder --os-volume-
And once you have the ID of the attachment, check the details with api-version= 3.27 attachment-show $ATTACHMENT_UUID"
"cinder --os-volume-
And see if the right attachment mode is present there.