Oi Jorge!
I've worked on the integration between cinder and 3par in the past, and mostly the issues are from the 3par side/reconf (chap)

Can you initialize a separate thread so we can also help you with that option? I believe it'll be the best for you in the long run.

What OSP version are you using? And what deployment strategy?

Cheers!

---
Alvaro Soto.

Note: My work hours may not be your work hours. Please do not feel the need to respond during a time that is not convenient for you.
----------------------------------------------------------
Great people talk about ideas,
ordinary people talk about things,
small people talk... about other people.

On Sat, Dec 23, 2023, 1:31 AM Pete Zaitcev <zaitcev@redhat.com> wrote:
On Fri, 22 Dec 2023 15:09:32 -0300
Jorge Visentini <jorgevisentini@gmail.com> wrote:

> So, of course, the best scenario is to use the vendor driver...

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.

With that in mind, this looks like a terrible idea:

" If I work directly with LVM, that is, deliver a LUN to
all my hosts, create an LVM and deliver it to Cinter, will I have the Live
Migration, HA instances, snapshot and other features ?"

How do you ensure that your hypervisors have the LVM information
consistent inside the LUNs you sliced up?

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.

-- Pete