I've had a few reports of people trying to run iscsid in a container, which doesn't work at all when using network namespaces. This is the start of me looking at what it would take to make that work, and if it makes sense at all. The first issue is that the kernel side of the iSCSI netlink control protocol only operates in the initial network namespace. But beyond that, if we allow iSCSI to be managed within a namespace we need to decide what that means. I think it makes the most sense to isolate the iSCSI host, along with it's associated endpoints, connections, and sessions, to a network namespace and allow multiple instances of the userspace tools to exist in separate namespaces managing separate hosts. It works well for iscsi_tcp, which creates a host per session. There's no attempt to manage sessions on offloading hosts independently, although future work could include the ability to move an entire host to a new namespace like is supported for network devices. 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. Thanks, Chris Chris Leech (4): iscsi: create per-net iscsi nl kernel sockets iscsi: sysfs filtering by network namespace iscsi: make all netlink multicast namespace aware iscsi: set netns for iscsi_tcp hosts drivers/scsi/iscsi_tcp.c | 7 + drivers/scsi/scsi_transport_iscsi.c | 264 +++++++++++++++++++++++++++++------- include/scsi/scsi_transport_iscsi.h | 2 + 3 files changed, 222 insertions(+), 51 deletions(-) -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
