https://bugzilla.redhat.com/show_bug.cgi?id=1100000
Vaibhav Khanduja <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #17 from Vaibhav Khanduja <[email protected]> --- (In reply to Chris Leech from comment #15) > I've spent some more time looking at running iscsid in a network namespace > container, and there are a number of kernel issues that need to be worked > out. > > The kernel side of the iSCSI netlink family only listens in the initial > network namespace (just like some other storage related netlink families). > It's easy enough to add per-namespace kernel sockets, a bit more work to > associate network namespaces to iSCSI objects in order to route async event > notifications to the right place. > > iSCSI makes heavy use of sysfs as well, and many of the iSCSI sysfs devices > will need network namespace tags for filtered views of sysfs. I think that > makes sense for iscsi_host, iscsi_session, and iscsi_connection. Certainly > not for iscsi_transport. Possibly for iscsi_endpoint and iscsi_iface. > > Without growing some way to assign an iscsi_host to a net namespace like is > done for network devices, this will probably work for dynamically generated > hosts (iscsi_tcp) but not for offload hardware. > > I can imagine use cases where it might be nice to have multiple iscsid > instances in their own containers managing their own set of iSCSI sessions. > > I've got some work started, but it's not ready for review and testing just > yet. > > Without that, I don't see how we can get to multiple working iscsid > processes or even a single iscsid running without --net=host do you have working patch? I wanted to test this out to check the working? -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ golang mailing list [email protected] https://lists.fedoraproject.org/mailman/listinfo/golang
