Mike Christie wrote: >On 07/01/2011 03:16 PM, Jim Ramsay wrote: >> Leading-login support only takes effect when performing >> "login-by-startup" (ie, iscsiadm -m node -L ...). For any nodes with >> this value set to "Yes" (The default is "No"), an attempt will be made >> on each successive iface record until the first one succeeds. The >> intent is to only have a single iSCSI session for each target >> regardless of the number of iface records in the system. > >For using ifaces we have 2 modes: > >1. We pass the ifaces we want to bind to portals to when we run commands >like the discovery command or the manual record creation command. When >you run the login command we will use those specific ifaces to login into the >portals that are setup in the discovery/rec-creation step. > >2. If you have ifaces setup that use iscsi_tcp but do not pass the iscsiadm >discovery command any ifaces, iscsiadm will use those default ifaces you had >setup like you had passed them in like in #1. > >For your feature it seems like you are doing something like #2. Did you want >to be able to control which ifaces you log into here?
We are doing something like #2, yes. And there is already a way to control which ifaces are used for login in this case, by setting 'node.startup = automatic' for the ifaces you want to login at startup and 'node.startup = manual' for those you do not: iscsiadm -m node -T <target-name> -I <iface-name> -o update -n node.startup -v manual iscsiadm -m node -T <target-name> -I <iface-name> -o update -n node.startup -v automatic While we could already use this same facility to limit the logins to only be automatic for exactly one iface record, there is no fall-through if the underlying network is down on the iface that is configured for automatic login. We need to introduce a fault-tolerant way to get only one session established. So here's a more verbose description of the intent and purpose of this patch: The current iscsiadm behavior is that when a user (or usually the distro startup script) runs 'iscsiadm -m node --loginall=automatic', iscsiadm loops through every node-iface record and for each one which has 'node.startup = automatic', it performs a login over the associated iface. This patch simply goes one step further than the current "loginall" logic. The user or distro script will still run 'iscsiadm -m node --loginall=automatic' and iscsiadm will still loop through all node-iface records that have 'node.startup = automatic'. For each one that has the new 'node.leading_login = No' (which is the default value), the loginall logic proceeds as before and initiates a login for that node over the associated iface, which may result in multiple sessions if that node is bound to multiple iface records. So here's the change: Then for those node-iface records that have 'node.leading_login = Yes', iscsiadm will try a login for each of the iface records in turn. Once the first login succeeds for that node, it will not try to establish a new session for that node on any other iface. (I suppose more accurately I could say that when iterating through records with 'node.leading_login = Yes', we will now only try to initiate a login if there are no current sessions established for that node.) In our specific use-case, we will normally want users to set up all the node records with 'node.startup = automatic' and 'node.leading_login = Yes' so that on startup the end result will be that every node has exactly one session and the startup process will automatically fall through to trying alternate iface records in the case of network availability issues. (Or in the case where the distro startup script uses 'onboot' instead of 'automatic', the exact same logic should work, just replace "automatic" with "onboot" in the text above.) >Also did you want to be able to set some sort of preference for which iface to >try first or in this situation does any-old-one work ok? This is an interesting idea; But for our needs, no. We don't care in which order we try the ifaces, as long as one eventually succeeds. I will be submitting v2 of this patch shortly, with some code-style cleanups. -- Jim Ramsay -- 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.
