Mike Christie wrote: > I started to do a pseudo patch to see how it would work
With the DHCP thing at hand possibly changing the initiator IP address, I think what we want to do for iser is use NIC names for ifaces as I do now for iscsi/tcp with the user taking care of NIC name persistently across reboots through udev et al. I hope we can implement a loop which goes over the ip address associated with this NIC and finds one of them which in the subnet of the target portal we're connecting to. This would be the source ip fed into the enhanced ep_connect exported by iser in the kernel. >>> # ip r s >>> 10.10.1.91 dev ib1 scope link >>> 10.10.0.91 dev ib0 scope link >>> 10.10.0.0/16 dev ib0 proto kernel scope link src 10.10.5.157 >>> 10.10.0.0/16 dev ib1 proto kernel scope link src 10.10.5.158 > With this do you get 2 paths then? For iface binding we want to try and > get 4. So if got really unlucky and ib0's port and the target portal > connected to ib1 died, then you could still have two usable paths. yes, I have two paths this way which serves me well at this point. Four paths may be problematic in case the system is a small scale one, e.g wired with two switches, each connected to all initiators and targets and there's 1-2 inter-switch-links (ISLs). Two paths are passing on ISL and should be prioritized lower then the two which don't, is there a way to do that? Or. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
