[stgt] Limiting the number of ISCSI-Sessions per target

[FUJITA Tomonori]

On Mon, 20 Oct 2008 06:14:52 +0200
Arne Redlich <agr at powerkom-dd.de> wrote:

> Am Montag, den 20.10.2008, 11:49 +0900 schrieb FUJITA Tomonori:
> > On Fri, 17 Oct 2008 18:05:14 +0200
> > "Dr. Volker Jaenisch" <volker.jaenisch at inqbus.de> wrote:
> > 
> > > Hello stgt developers!
> > > 
> > > I have a HA XEN-setup based on ISCSI devices [tgtd (target) and
> > > open-iscsi (initiator)]
> > > as physical devices for the XEN DomUs.
> > > 
> > > In case of a split-Brain in the HA-System more than one machine may
> > > fetch a iSCSI-Session and may try to bring up a XEN-VM on it. This will seriously damage the
> > > filesystem.
> > > 
> > > Therefore I like to limit the number of iSCSI sessions to one 
> > > session per target, simultaneously
> > > 
> > > Is there a way to limit the number of ISCSI-Sessions per Target-ID?
> > > I found the MaxConnection-Parameter but it limits only the number of
> > > connections within a single iSCSI-Session.
> > 
> > Yeah, MaxConnection is iSCSI legitimate parameter.
> > 
> > 
> > > Is there something alike - say a MaxSession-Parameter?
> > 
> > There is no standard way to do such. IET used to support MaxSessions
> > parameter to limit the maximum number of sessions per target. We could
> > add the same feature to tgt, but IET disables the feature now. Anyone
> > can recall why? Well, probably I disabled it but I can't recall
> > anything.
> 
> It was disabled it because we could not detect whether the initiator
> holding this "lock" was alive.

Ah, thanks!


> IMO such a parameter really requires proper NOP-In support.

Yeah, probably. But the feature would be fine if an administrator
fixes the above situation by hand. In the case of HA systems, they
have the own mechanism to detect if an initiator is dead or alive. So
they could use the feature nicely, I guess.
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html