On 02/25/2010 06:03 AM, Or Gerlitz wrote:
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.
I think on the target side you normally use static ips (I think you
normally have a lot fewer target portals than initiators). People also
actually do use hostnames for the target portals too. There have been a
couple bug reports on the list on how open-iscsi does not support them
correctly.
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.
Do you mean you need a src IP for rdma_resolve_addr? If so, if you have
a src ip, can you override what rdma_resolve_addr gives you for cases
like where you have two ports on the same subnet?
--
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.
