Hi Mike, Thanks. Can you please try --target=i686.
On the patches, yes, I will include it in our next VM kernel. regards Guru Mike Christie wrote: > ccing Guru Anbalagane. > > Hoot, Joseph wrote: >> Sure. Its the OVM 2.2 environment that I talked with you about a >> couple of days ago. Here is the info: >> > > Doh! I forgot. > > Guru, I am trying to make a patch for your Oracle VM kernel. I want to > port the patch I told you about > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=4c48a82935f833d94fcf44c2b0c5d2922acfc77a;hp=d1acfae514425d680912907c6554852f1e258551 > > > and this one: > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d1acfae514425d680912907c6554852f1e258551 > > > if you do not have it (could not remember if you did or not). > > I found the src rpm: > http://edelivery.oracle.com/EPD/Download/get_form?egroup_aru_number=11874896 > > > The problem is that I keep getting RPM build errors when I try to > build the project: > > rpm -ivh kernel-2.6.18-128.2.1.4.9.el5.src.rpm > rpmbuild -bp --target=noarch /usr/src/redhat/SPECS/kernel-2.6.spec > > ... a bunch of stuff then > > make[1]: *** [nonint_oldconfig] Error 15 > make: *** [nonint_oldconfig] Error 2 > error: Bad exit status from /var/tmp/rpm-tmp.94270 (%prep) > > > RPM build errors: > Bad exit status from /var/tmp/rpm-tmp.94270 (%prep) > (have also tried without the --target arg and with different archs and > always fails) > > This is how I setup the RHEL kernel source rpm. Are the commands for > the Oracle VM kernel different? > > > >> [r...@oim6102506 ~]# uname -r >> 2.6.18-128.2.1.4.9.el5xen >> [r...@oim6102506 ~]# rpm -qa | grep iscsi >> iscsi-initiator-utils-6.2.0.871-0.7.el5 >> >> I have a tcpdump that I had sent to Don WIlliams. I'll pull that up >> shortly. >> >> On Nov 17, 2009, at 10:06 PM, Mike Christie wrote: >> >>> Mike Christie wrote: >>>> Hoot, Joseph wrote: >>>>> more INLINE below... >>>>> >>>>> On Nov 17, 2009, at 7:27 PM, Mike Christie wrote: >>>>> >>>>>> Pasi Kärkkäinen wrote: >>>>>>> On Mon, Nov 16, 2009 at 09:39:00PM -0500, Hoot, Joseph wrote: >>>>>>>> On Nov 16, 2009, at 8:19 PM, Hoot, Joseph wrote: >>>>>>>> >>>>>>>>> thanks. That helps. So I know that with the EqualLogic >>>>>>>>> targets, there is a "Group IP" which, I believe, responds with >>>>>>>>> an iscsi login_redirect. >>>>>>>>> 1) Could the "Login authentication failed" message be the >>>>>>>>> response because of a login redirect messages from the EQL >>>>>>>>> redirect? >>>>>>>>> >>>>>>>>> and then my next question is more for curiosity sake: >>>>>>>>> >>>>>>>>> 2) Are there plans in the future to have more than one >>>>>>>>> connection per session? and I guess in addition to that, >>>>>>>>> would that mean multiple connections to a single volume over >>>>>>>>> the same nic? >>>>>>>>> >>>>>>>>> >>>>>>>> Also Mike, I'm seeing one or two of these every 30-40 minutes >>>>>>>> if I slam our EqualLogic with roughly 7-15k IOPS (reads and >>>>>>>> writes) non stop on 3 volumes. In this type of scenario, would >>>>>>>> you expect to see timeouts like this once in awhile? If so, do >>>>>>>> you think increasing my NOOP timeouts would assist so we don't >>>>>>>> get these? maybe set it to 15 seconds instead of 10? >>>>>>>> >>>>>>> Equallogic does active loadbalancing (redirects) during operation.. >>>>>>> dunno about the errors though. >>>>>>> >>>>>> Oh yeah, forgot about that. Thanks Pasi! >>>>>> >>>>>> Joseph, look in the EQL target logs for something about the EQL >>>>>> box doing load balancing. I think normally we handle the load >>>>>> balancing more gracefully, but we might be messing up. I think if >>>>>> EQL was load balancing in the open-iscsi logs we would see >>>>>> something about getting a async iscsi pdu from the target that >>>>>> asks us to logout. Then when we relogin the target would redirect >>>>>> us to the optimal path. >>>>> There are two things that the EQL does, I believe-- one thing is >>>>> async logout, the other is login_redirect. Unfortunately, from >>>>> the EQL syslog side we don't see any errors related to this. It's >>>>> my understanding, however, that when a login is initially >>>>> attempted to the EQL, it hits the "group ip" or an alias'd IP >>>>> sitting on a real nic. The group IP looks at all the interfaces >>>>> on the EQL and decides, based on some algorithm, which EQL nic the >>>>> session should connect to. It then sends the initiator that made >>>>> the request a login_redirect, which I thought is basically a >>>>> "logout and reconnect" pdu. It would say, for example, "you're >>>>> can't log into the group IP, however, you can log into this IP (a >>>>> real nic) that it would prefer you be logged into." >>>>> >>>>> I'm thinking that the "failed login" is actually the result of >>>>> that attempt to log into the group IP and it sending a login >>>>> redirect pdu back to it. >>>>> >>>> If the target was load balancing us it would: >>>> >>>> - Send a async logout pdu. >>>> - We then send a logout pdu. >>>> - When we get the logout response pdu we kill the tcp ip connection >>>> - We then create a new tcp connection >>>> - We then log in to the portal that was passed into iscsiadm/iscsid >>>> (the one in the DB that you see when you run iscsiadm -m node, >>>> which is probably what you call the group IP). For this process we >>>> send a login pdu. It then sends a login response pdu with the login >>>> redirect response. In this response we also get the new IP to log >>>> into. >>>> - We see that response and kill the tcp connection, and create a >>>> new tcp connection to the portal we are being redirected to. >>>> - We then log into the portal we were redirected to. We again do >>>> this by sending a login pdu. This time the login response pdu >>>> should be ok and we are done. >>> Oh yeah, I meant to also say that this is pretty much the same >>> process that happens we do the first login, and if we have to >>> relogin because of a connection problem like the nop/ping timeout. >>> The only difference in those cases is that we do not get the async >>> logout and we do not do a logout by sending a logout pdu. We start >>> at the killing tcp ip connection step. >>> >>> So even if we are not getting load balanced we would be in the same >>> place in the open-iscsi code when we are getting the login failed >>> errors. >>> >>> >>> To get back on track solving why we get the nop timeouts then if we >>> are not seeing load balancing messages or async logout messages, it >>> could be the open-iscsi bug I mentioned in the other mail. If you >>> can send the open-iscsi and kernel info I asked for in the other >>> mail, we can start down that path. >>> >>> -- >>> >>> 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=. >>> >>> >> >> =========================== >> Joseph R. Hoot >> Lead System Programmer/Analyst >> (w) 716-878-4832 >> (c) 716-759-HOOT >> [email protected] >> GPG KEY: 7145F633 >> =========================== >> >> -- >> >> 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=. >> >> > -- 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=.
