Hi Pete!
Note that your guests exchange the data with 3PAR without any "vendor driver". You can export volume from the array with iscsi, or over FC. The reason why Cinder uses a "driver" is to manage your LUNs without LVM. When a request comes to allocate a volume, Cinder then invokes a driver (such as 3PAR) in order to talk to the array and obtain the LUN, which can be attached to your guest by Nova.
- I didn't know that it is possible to work with 3PAR without the "vendor driver". My only test was with the driver, doing exactly what you said: Manage your LUNs without LVM.
How do you ensure that your hypervisors have the LVM information consistent inside the LUNs you sliced up?
- Yeah... I'm used to oVirt, so oVirt has a system that controls the consistency of LVM information. I couldn't say about OpenStack. But it's probably not the right way to work. I mean, it wouldn't be a good practice.
My suggestion is to use one LUN per one OpenStack volume and not try to subdivide them with LVM.
Your guests can use LVM on volumes that are attached to them, of course.
But that has nothing to do with Cinder driver.
- Yes, I understood. That's exactly what I want to do.
But I keep thinking... one LUN per volume... if an instance has four volumes, then I will have four LUNs... I don't know if it's a bit exaggerated, talking about, for example, 300 volumes haha. But I understand your logic.
It really clarified me a lot!
Many thanks, Pete!