ISCSI LVM usage: just one PV per VG?

[pille]

hi,

i'm playing with ISCSI storage at the moment and have multiple targets.
i want to join them to a volume group that is used as shared storage.
in future i want to add more targets to the VG, as i need/buy more storage.

this setup doesn't seem to be possible with the web-gui.
i can only assign one target (PV) to one VG.

doing what i want is possible on the command-line. i can add whatever i want to my VG.
my question: is this still secure for the data?
in storage.cfg there's a base for my LVM, which is the first ISCSI target (i added with the web-gui). what is this information used for? are multiple bases ok?
proxmox does some kind of locking for shared storage to avoid using a LV multiple times.
can you outline your locking mechanism, or define what is dangerous and what not?

how am i supposed to use LVM/ISCSI the way you thought of?
will anything of the information requested change in PVE2.x?

pille

 

[dietmar]

doing what i want is possible on the command-line. i can add whatever i want to my VG.
my question: is this still secure for the data?

Using different PVs is not supported because the side effects are totally unclear (performance, failure modes, write barriers, locking, ..)
We don't want to deal with that complexity.

how am i supposed to use LVM/ISCSI the way you thought of?

Simply use one PV per VG - what is the problem?

 

[whinpo]

yes please, where is the problem?

I use 2 targets with 1 PV on each and that's enough for example to allow me to put my "tests VM" on another storage...

neptune2:~# pvs
  PV         VG             Fmt  Attr PSize  PFree
  /dev/dm-3  Proxmox-SR     lvm2 a-    2.00T 1.61T
  /dev/dm-4  ProxmoxTest-SR lvm2 a-    2.00T 1.68T

 

[pille]

hi dietmar,

Using different PVs is not supported because the side effects are totally unclear (performance, failure modes, write barriers, locking, ..)
We don't want to deal with that complexity.

would be nice to know in advance. if i hear LVM i think of all the features. this limitation should be worth mentioning in the wiki.

Simply use one PV per VG - what is the problem?

that limits the whole concept of LVM. VGs weren't invented as an additional useless layer.
i have no direct access to the SAN, as it's maintained by another department.
if i need more space, i can say that and they'll do it. they can resize the target and i can resize the PV, but that would affect all VMs.
so the plan is they give me another target which is independent, i integrate that in the VG and everything's fine.
but i don't want to end up having dozens of VGs.

can you please answer the other questions from my first post?

 

[dietmar]

i have no direct access to the SAN, as it's maintained by another department.
if i need more space, i can say that and they'll do it. they can resize the target and i can resize the PV, but that would affect all VMs.

Why? LVs should not be affected at all by that?

can you please answer the other questions from my first post?

No, I do not have the time to do that - please that a look at the code if you want to know how it works.

 

[pille]

Why? LVs should not be affected at all by that?

they cannot resize the LUN without data loss.

No, I do not have the time to do that - please that a look at the code if you want to know how it works.

then please take the time to answer that one specific question from above: will anything of the information requested change in PVE2.x?
(is the storage model stable between 1.x and 2.x or will i have to reimplement patches to a completly different architecture (like your cluster communication will change)

 

[dietmar]

(is the storage model stable between 1.x and 2.x or will i have to reimplement patches to a completly different architecture (like your cluster communication will change)

No, we do not plan a completely different architecture.