On Wed, May 20, 2015 at 11:45:43AM -0700, Andy Grover wrote:
> On 05/13/2015 03:12 PM, Chris Leech wrote:
> >This is only about the structures and functionality involved in maintaining 
> >the
> >iSCSI session, the SCSI host along with it's discovered targets and devices 
> >has
> >no association with network namespaces.
> >
> >These patches are functional, but not complete.  There's no isolation 
> >enforced
> >in the kernel just yet, so it relies on well behaved userspace.  I plan on
> >fixing that, but wanted some feedback on the idea and approach so far.
> 
> Seems like a good direction, to me.
> 
> What would be the extent of the userspace (open-iscsi) changes needed to go
> along with this?

There's no core changes needed in the open-iscsi tools, it's more a
matter of how iscsid is packaged and executed.

The control socket between iscsid and iscsiadm binds to an abstract unix
domain path, so that works fine as long as you run iscsiadm from within
the same net ns as the iscsid instance you want to talk to.

The pid file checks clash if /var/run is common between instances.
Putting iscsid in a container could provide separate config files and
configuration databases, but there may be something that could improve
handling there.

I've been testing using 'ip netns exec' to run iscsid in a new network
namespace (it actually crates a new mount namespace as well, to remount
/sys with the new namespace filtered view).

My test setup so far has been the following:

  A VM with two virtio network interfaces on different virtual networks.
  I have an iSCSI target configured with two portals, one on each
  virtual network.

  I create two new network namespaces with 'ip netns add' and then move
  the nics into them with 'ip link <dev> netns <ns>' and bring them
  online.

  Using 'ip netns exec' I start up an iscsid instance in each namespace,
  using the --foreground option to avoid the PID file clash.

  Form within each namespace I can run iscsiadm to manage sessions
  through one of the iscsid instances.  With this setup they share the
  persistent configuration database, so I specifically select which
  records to start/stop.

- Chris

-- 
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Reply via email to