[Bug 208469] Re: open-iscsi can fail to start if any portals are unavailable, even if other portals are fine

Dave Gilbert ubuntu at treblig.org
Sat Sep 1 23:35:41 UTC 2012

my config; performed on Quantal server daily iso 2012-09-01

** Attachment added: "Configuration of my iscsi setup"

You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to open-iscsi in Ubuntu.

  open-iscsi can fail to start if any portals are unavailable, even if
  other portals are fine

Status in “open-iscsi” package in Ubuntu:
  Fix Released

Bug description:
  Binary package hint: open-iscsi

  Many enterprise-class iSCSI systems use multiple portals to access a
  single target.  For example you can have 2 or 3 different network
  pathways to a target, each with its own portal IP.  open-iscsi
  supports this fine, however the current startup scripts do not handle
  pathway failure gracefully.

  Imagine this scenario:

  A target: iqn.2008-03.com.something.target.t

  3 portals:

  On startup, open-iscsi goes through the list of portals and brings
  them up one by one.  It seems to progress in alphabetical order, so in
  the case above will start up first.  Once the session has
  been established to that portal, open-iscsi will proceed to the next
  portal, and so on.  Once we are up and running, multipath handles
  portal failures, load balancing, etc.  After boot time we can safely
  kill off 2 of the 3 portals and we still have a pathway to our iSCSI

  At boot time however, open-iscsi will fail to start if it hits a
  portal that cannot be reached.  In the case above where we have a
  triple-redundant portal we only need one of the 3 portals to be
  "alive".  However, as soon as open-iscsi hits a "dead" portal it will
  exit with a failure and will not proceed to the next portal.  This
  actually provides significantly LOWER reliability as we could easily
  have one portal offline for maintenance, etc without impacting running
  systems, but no other systems would be able to start up or be rebooted
  even though the SAN itself is still operational!

To manage notifications about this bug go to:

More information about the foundations-bugs mailing list