limiting iSCSI / FC target concurrent access

Hi,

I'd like to limit the number of concurrent accesses to iSCSI and FC targets - in my case effectively to "1" :) That way I could make sure only one initiator at a time is accessing the volumes (as you may have guessed I'm talking about cluster environments).

I haven't found anything alike in the docs - OTOH, this should be easy to implement on the server (target) side. Have I overseen an option or is this currently not possible? If not possible right now, are there any plans to add such a feature in the (near) future?

With regards,

Jens

PS: I know cluster file systems with their distributed locking features could be used to limit access to shared file resources, but I'm looking at an alternative approach using FC (and iSCSI) devices for performance reasons - no need for a cluster FS if you simply want "one resource at a time" access. The FC / iSCSI targets in questions are the "disks" of Xen VMs, we're planing to use direct NPIV and iSCSI access within the VM configuration.

With iSCSI you can restrict the server access with IP Address Allow and Deny.
You can also use CHAP to restrict users.

Quote:

---

Originally Posted by To-L

With iSCSI you can restrict the server access with IP Address Allow and Deny.
You can also use CHAP to restrict users.

---

The problem is, all users/systems (redundant Xen servers) have a need to be permitted to access the resource - it's just that they shouldn't access concurrently.


With regards,
Jens

<bump />

Any information available on this? Has anybody within development put this on some "enhancement wishlist" or is this a wish never to come true?

<summary>
I see a requirement to limit *concurrent* connections to FC targets, at least concerning write access, to "1".

Szenario: Multiple Xen servers where VMs access FC resources directly, ie via NPIV connections. Concurrently active VMs accessing the same FC resources (ie by misconfiguration) will cause severe damage. This can not be avoided via access lists, as access has already been restricted to one (NPIV) port ID.

Solution: Enhance the FC code to only allow new connects to the FC target when no other connections exists.
</summary>

Well, if you add the FC volume in question to a group besides the "Default" one in "Configuration"->"FC target manager", then you can make sure that only the WWN aliases that you select are able to access the FC volumes in that group.


We just installed a dss at a customer who is going to use it as a FC box. They really like the feature to be able to bind volumes to WWN Aliases so they don't have to worry about corruption from concurrent access (this is a feature they didn't have in their old FC box).

Quote:

---

Originally Posted by Robotbeat

Well, if you add the FC volume in question to a group besides the "Default" one in "Configuration"->"FC target manager", then you can make sure that only the WWN aliases that you select are able to access the FC volumes in that group.


We just installed a dss at a customer who is going to use it as a FC box. They really like the feature to be able to bind volumes to WWN Aliases so they don't have to worry about corruption from concurrent access (this is a feature they didn't have in their old FC box).

---

As I had tried to mention in my original messages, this is not sufficient: If we run a VM from more than one server, then both servers need access to the FC resource.

We already have stripped down access to single VMs (via virtual WWNs per NPIV access, plus according groups in the SAN server) - but when either the VM is started multiple times (should not happen due to Stonith) or accidentially a configuration is copied without changing the NPIV address, then you run into trouble.

With regards,

Jens