Don: Agreed. I have been playing with podman, and I actually have a working prototype! Right now, I'm looking how to end sessions started in a container. Just killing the container leaves a dangling session.
On Wednesday, February 8, 2023 at 12:10:37 PM UTC-8 [email protected] wrote: > I agree that sharing the initiator name and the other config files would > not be recommended. > > The initiator name is often used as an access controll method on the > target. Which could lead to double mounting volumes. > > Also one benefit would be better isolating an iSCSI SAN with multiple > customers accessing the SAN via unique containers. > > It should be possible to specify those files and directories as part of > the container config. > > Don > > On Wed, 2023-02-08 at 11:17 -0800, The Lee-Man wrote: > > I wanted to mention some issues I've discovered as part of testing this: > > > - Currently, only some sysfs entries are going to be different per > namespace > - This means that the Configuration and Initiator Name are going to be > common to all running daemons (this is /etc/iscsi) > - This also means that the Node database (and discovery DB, and > interface DB) are common to all running daemons > > I'm really not sure all running daemons should have the same initiator > name. If we think of them as separate initiators, then this seems wrong. > > Sharing the Node database may not be a good idea, either. This assumes > that nodes discovered (and saved) from one namespace can actually be > reached from other namespaces, but this may not be true. Having the Node DB > and initiatorname shared means the different iscsid instances must > cooperate with each other, else their requests can collide. Also, I can > imagine situations where different daemons may want to set different > configuration values. Currently they cannot. > > On Wednesday, February 8, 2023 at 9:41:02 AM UTC-8 The Lee-Man wrote: > > From: Lee Duncan <[email protected]> > > This is a request for comment on a set of patches that > modify the kernel iSCSI initiator communications so that > they are namespace-aware. The goal is to allow multiple > iSCSI daemon (iscsid) to run at once as long as they > are in separate namespaces, and so that iscsid can > run in containers. > > Comments and suggestions are more than welcome. I do not > expect that this code is production-ready yet, and > networking isn't my strongest suit (yet). > > These patches were originally posted in 2015 by Chris > Leech. There were some issues at the time about how > to handle namespaces going away. I hope to address > any issues raised with this patchset and then > to merge these changes upstream to address working > in working in containers. > > My contribution thus far has been to update these patches > to work with the current upstream kernel. > > Chris Leech/Lee Duncan (9): > iscsi: create per-net iscsi netlink kernel sockets > iscsi: associate endpoints with a host > iscsi: sysfs filtering by network namespace > iscsi: make all iSCSI netlink multicast namespace aware > iscsi: set netns for iscsi_tcp hosts > iscsi: check net namespace for all iscsi lookup > iscsi: convert flashnode devices from bus to class > iscsi: rename iscsi_bus_flash_* to iscsi_flash_* > iscsi: filter flashnode sysfs by net namespace > > drivers/infiniband/ulp/iser/iscsi_iser.c | 7 +- > drivers/scsi/be2iscsi/be_iscsi.c | 6 +- > drivers/scsi/bnx2i/bnx2i_iscsi.c | 6 +- > drivers/scsi/cxgbi/libcxgbi.c | 6 +- > drivers/scsi/iscsi_tcp.c | 7 + > drivers/scsi/qedi/qedi_iscsi.c | 6 +- > drivers/scsi/qla4xxx/ql4_os.c | 64 +-- > drivers/scsi/scsi_transport_iscsi.c | 625 ++++++++++++++++------- > include/scsi/scsi_transport_iscsi.h | 63 ++- > 9 files changed, 537 insertions(+), 253 deletions(-) > > > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/open-iscsi/7df2eb67-99f0-412a-82f8-2501d36b45bcn%40googlegroups.com.
