Hi Mike: I tested your patch, and it fixes the issue I was seeing with Emulex cards using the be2iscsi driver.
I thought about the upgrade implications while testing on this system, and I discussed my results with Hannes. It looks like there should not be an upgrade issue. Instead, a system being upgraded with be2iscsi would end up with three interface files for each interface: the original interface file, named: * be2iscsi.MAC_ADDR -- the original interface file * be2iscsi.MAC_ADDR.ipv4.0 -- a new interface file for IPv4 * be2iscsi.MAC_ADDR.ipv6.0 -- a new interface file for IPv6 So I would say go ahead and submit this patch. :) On Friday, May 27, 2016 at 2:46:31 PM UTC-7, Mike Christie wrote: I think we can do something like the attached compile tested only patch which has the boot code use the same iface name format as the normal setup. My concern was compat support. The patch will use whatever the kernel supports, and so it should just work for boot if you are using iscsistart or "iscsiadm -m fw -l", but I am not sure if during a upgrade things will work with mismatch of old and new kernel and tools and old stored /etc/ifaces and how distros were using the tools. I got busy with day time work stuff, and I killed my card (updated the fw and now it only supports networking instead of iscsi and I cannot covert back) so I was not able to go over all the combos. If you can test it out it and think of the SUSE upgrade scenarios you guys support it would help. On 05/27/2016 01:13 PM, The Lee-Man wrote: > Mike: I know you've been busy. Any progress on this? Can I help, as I > have the same issue? > > On Thursday, October 8, 2015 at 2:48:30 PM UTC-7, Mike Christie wrote: > > On 10/08/2015 04:10 PM, Ferenc Wagner wrote: > > Mike Christie <m*@cs.wisc.edu> writes: > > > >> > On 10/7/15, 1:37 AM, Ferenc Wagner wrote: > >> > > >>> >> In a pristine system (iscsistart only, no targets configured by > >>> >> iscsiadm) I only get two sessions (with short interfaces > names). With > >>> >> an older open-iscsi version I could then add the four needed > node, and > >>> >> after login iscsid took over the two from iscsistart and also > started > >>> >> the two other. Now, that iscsid uses long interface names, > it creates > >>> >> four new sessions and leaves the two from iscsistart > unmanaged. Than > >> > > >> > How do you know they are unmanaged by iscsid? Is the iscsid > session > >> > state in the iscsiadm -m session -P 1 info showing: > >> > > >> > Internal iscsid Session State: Unknown > > Maybe I was wrong on this point. After an iscsistart -b in the > > initramfs, but with no ifaces or nodes configured later: > > No problem. I think I fully understand the problem. I am working on a > patch. I messed up the firmware on my card, so I cannot access the boot > setup any more here, but am looking for one in the red hat lab. > > -- > You received this message because you are subscribed to the Google > Groups "open-iscsi" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/open-iscsi. > For more options, visit https://groups.google.com/d/optout. Hi Mike: I tested your patch, and it fixes the issue I was seeing with Emulex cards using the be2iscsi driver. I thought about the upgrade implications while testing on this system, and I discussed my results with Hannes. It looks like there should not be an upgrade issue. Instead, a system being upgraded with be2iscsi would end up with three interface files for each interface: the original interface file, named: * be2iscsi.MAC_ADDR -- the original interface file * be2iscsi.MAC_ADDR.ipv4.0 -- a new interface file for IPv4 * be2iscsi.MAC_ADDR.ipv6.0 -- a new interface file for IPv6 On Friday, May 27, 2016 at 2:46:31 PM UTC-7, Mike Christie wrote: > > I think we can do something like the attached compile tested only patch > which has the boot code use the same iface name format as the normal > setup. > > My concern was compat support. The patch will use whatever the kernel > supports, and so it should just work for boot if you are using > iscsistart or "iscsiadm -m fw -l", but I am not sure if during a upgrade > things will work with mismatch of old and new kernel and tools and old > stored /etc/ifaces and how distros were using the tools. > > I got busy with day time work stuff, and I killed my card (updated the > fw and now it only supports networking instead of iscsi and I cannot > covert back) so I was not able to go over all the combos. If you can > test it out it and think of the SUSE upgrade scenarios you guys support > it would help. > > > On 05/27/2016 01:13 PM, The Lee-Man wrote: > > Mike: I know you've been busy. Any progress on this? Can I help, as I > > have the same issue? > > > > On Thursday, October 8, 2015 at 2:48:30 PM UTC-7, Mike Christie wrote: > > > > On 10/08/2015 04:10 PM, Ferenc Wagner wrote: > > > Mike Christie <m*@cs.wisc.edu> writes: > > > > > >> > On 10/7/15, 1:37 AM, Ferenc Wagner wrote: > > >> > > > >>> >> In a pristine system (iscsistart only, no targets configured > by > > >>> >> iscsiadm) I only get two sessions (with short interfaces > > names). With > > >>> >> an older open-iscsi version I could then add the four needed > > node, and > > >>> >> after login iscsid took over the two from iscsistart and also > > started > > >>> >> the two other. Now, that iscsid uses long interface names, > > it creates > > >>> >> four new sessions and leaves the two from iscsistart > > unmanaged. Than > > >> > > > >> > How do you know they are unmanaged by iscsid? Is the iscsid > > session > > >> > state in the iscsiadm -m session -P 1 info showing: > > >> > > > >> > Internal iscsid Session State: Unknown > > > Maybe I was wrong on this point. After an iscsistart -b in the > > > initramfs, but with no ifaces or nodes configured later: > > > > No problem. I think I fully understand the problem. I am working on > a > > patch. I messed up the firmware on my card, so I cannot access the > boot > > setup any more here, but am looking for one in the red hat lab. > > > > -- > > You received this message because you are subscribed to the Google > > Groups "open-iscsi" group. > > To unsubscribe from this group and stop receiving emails from it, send > > an email to [email protected] > > <mailto:[email protected]>. > > To post to this group, send email to [email protected] > > <mailto:[email protected]>. > > Visit this group at https://groups.google.com/group/open-iscsi. > > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
