[Cinder][LVM backend] LVM vg backed by a shared LUN
Hi,
The examples I could find on the internet using LVM as backend for Cinder, they expose a local disk using lvm via Cinder.
I did this configuration and I am wondering if it's correct, especially from a "simultaneous access" point of view.
I have an iSCSI target backed by targetcli that exposes a LUN to my compute nodes. I did configure the iscsi connexion manually on each one of them and they all see the LUN, then on one of them I created the cinder-volumes VG (the other nodes can see the modifications), then I configured Cinder with lvm backend using this VG and it worked. I created some volumes on it without issues using my account. But what about when there are multiple tenants that try to create multiple volumes on it, is this configuration safe?
Regards.
Hi,
On Wed, Apr 26, 2023 at 4:42 PM wodel youchi wodel.youchi@gmail.com wrote:
Hi,
The examples I could find on the internet using LVM as backend for Cinder, they expose a local disk using lvm via Cinder.
I did this configuration and I am wondering if it's correct, especially from a "simultaneous access" point of view.
I have an iSCSI target backed by targetcli that exposes a LUN to my compute nodes. I did configure the iscsi connexion manually on each one of them and they all see the LUN, then on one of them I created the cinder-volumes VG (the other nodes can see the modifications), then I configured Cinder with lvm backend using this VG and it worked. I created some volumes on it without issues using my account. But what about when there are multiple tenants that try to create multiple volumes on it, is this configuration safe?
I might not be 100% correct but I don't think it should affect anything. The backend, here LVM, doesn't have any information of the LUN association with the project and OpenStack does the management of associating volumes (OpenStack terminology of LUNs) with a particular project also managing the access via keystone roles and scopes. The backend shouldn't worry about the access of a LUN from a different project since "project" is an OpenStack concept which is handled in the OpenStack layer itself. Unless a LUN export/map request is coming from outside of OpenStack, proper authorization and authentication should be maintained.
Thanks Rajat Dhasmana
Regards.
On 26/04, wodel youchi wrote:
Hi,
The examples I could find on the internet using LVM as backend for Cinder, they expose a local disk using lvm via Cinder.
I did this configuration and I am wondering if it's correct, especially from a "simultaneous access" point of view.
I have an iSCSI target backed by targetcli that exposes a LUN to my compute nodes. I did configure the iscsi connexion manually on each one of them and they all see the LUN, then on one of them I created the cinder-volumes VG (the other nodes can see the modifications), then I configured Cinder with lvm backend using this VG and it worked. I created some volumes on it without issues using my account. But what about when there are multiple tenants that try to create multiple volumes on it, is this configuration safe?
Regards.
Hi,
I don't understand which of these 2 scenarios you have:
- You are sharing an LVM volume manually without using Cinder with each compute node and then you want to use the same LVM VG with Cinder for dynamically allocated volumes.
- You manually connected a volume to each compute to confirm that everything was working as expected and then you disconnected them and are using Cinder to dynamically allocate volumes for computes.
Even though I don't understand which one is your scenario, it doesn't matter as both should be safe as long as the target iqn you defined for your manual volumes don't use the same format as cinder volumes (to avoid possible collision with a volume created from Cinder) because Cinder LVM+LIO uses a per-volume target, so there won't be conflict with the ones you create manually nor will Cinder touch what you already have there.
Cheers, Gorka.
participants (3)
-
Gorka Eguileor
-
Rajat Dhasmana
-
wodel youchi