Mike Christie wrote: > I am fine with either. The netdev name (ethX) also has the same problems > where udev can change it. It is there for aliases or vlans where we > cannot use hwaddress since multiple netdevs have the same MAC.
yes, correct both netdevice name and hwaddress suffer from what you describe, shit happens. > Do you have similar issues with ib device names? with out HW changes no, if someone plugs in another card of the same type between two boots then yes. > What about bonding? Can you use bonding/trunking with iser? Is that going to > cause troubles? yes, indeed, we support bonding but unlike in ethernet where the bond MAC address is typically that of the current/active slave device, over ipoib, bonding automatically set the fail_over_mac option to active and the bond HW address is the one of the active slave which means we don't want an iscsi iser interface to be associated to hwaddress in that case. So we are remained with net device names or ip addresses, I don't want to go on hw device names since the whole addressing framework of iser is the same as the one used for TCP e.g based on IP addresses. I prefer the source IP address or at least the source ip address and mask, through which I can get a source ip on this subnet, even as of DHCP between reboots the source ip has been changed. thinking on this a bit more, DHCP related changed between reboots can be quite destructive to iscsi/nfs etc since the target IP can change. If this is the case and one really want to avoid that, one needs to use host names for the portal and not ip addresses, isn't it? this looks to me like going a bit too far away. All in all, when non default interface is needed/used (e.g for multipathing), I am quite sure we need to have some sort of source ip for iser in ep_connect, please let me know what you think would be the easy/best or close to either of (...) way to have 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 open-is...@googlegroups.com. To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/open-iscsi?hl=en.
