[storage-discuss] test
test From: storage-discuss-requ...@opensolaris.org Subject: storage-discuss Digest, Vol 59, Issue 5 To: storage-discuss@opensolaris.org Date: Thu, 11 Nov 2010 12:00:07 + Send storage-discuss mailing list submissions to storage-discuss@opensolaris.org To subscribe or unsubscribe via the World Wide Web, visit http://mail.opensolaris.org/mailman/listinfo/storage-discuss or, via email, send a message with subject or body 'help' to storage-discuss-requ...@opensolaris.org You can reach the person managing the list at storage-discuss-ow...@opensolaris.org When replying, please edit your Subject line so it is more specific than Re: Contents of storage-discuss digest... Today's Topics: 1. Re: crash dump after comstar install (Greg Terkanian) 2. Re: crash dump after comstar install (Greg Terkanian) 3. Re: Relationship between volume, LU, target,target group, etc. (Sumit Gupta) 4. Re: crash dump after comstar install (James C. McPherson) -- Message: 1 Date: Wed, 10 Nov 2010 05:53:50 PST From: Greg Terkanian gr...@crystalcomputer.com To: storage-discuss@opensolaris.org Subject: Re: [storage-discuss] crash dump after comstar install Message-ID: 1642722467.121289397261730.javamail.tweb...@sf-app1 Content-Type: text/plain; charset=UTF-8 David, Thanks for your response. I don't understand. I removed the driver from the BE and installed the Adaptec provided package. Perhaps they are one in the same? -Greg -- This message posted from opensolaris.org -- Message: 2 Date: Wed, 10 Nov 2010 06:20:34 PST From: Greg Terkanian gr...@crystalcomputer.com To: storage-discuss@opensolaris.org Subject: Re: [storage-discuss] crash dump after comstar install Message-ID: 803392210.141289398865702.javamail.tweb...@sf-app1 Content-Type: text/plain; charset=UTF-8 David, Can you please explain to me how you can tell it's the snv_134 version of the driver? Here are the steps I performed to test COMSTAR: - Built system - Removed SUN provided aac driver - Installed the adaptec provided driver - Rebooted - Ran system for months as-is.when I attempted iSCSI, system became unresponsive on regular basis - Installed COMSTAR (on active BE) - Reboot, panic - Rebuilt entire system (and installed adaptec provided drivers) - Upgraded fw/bios on adaptec card and upgraded driver on system - Rebooted and ran for a few days - Created a new BE and installed COMSTAR on it via pkg install storage-server SUNWiscsit - Boot to new BE and kernel panic - Reverted to prior BE My current output of modinfo shows: 189 f8026000 128d0 94 1 aac (AAC Driver 2.3.6) Thanks, Greg -- This message posted from opensolaris.org -- Message: 3 Date: Wed, 10 Nov 2010 11:17:23 -0800 From: Sumit Gupta sumitgu...@vmware.com To: Peter Taps ptr...@yahoo.com, storage-discuss@opensolaris.org storage-discuss@opensolaris.org Subject: Re: [storage-discuss] Relationship between volume, LU, target, target group, etc. Message-ID: cfea42e5b243a14cb0a85079c670cd5103e16c4ed...@exch-mbx-5.vmware.com Content-Type: text/plain; charset=us-ascii Hi Peter Before going into details, overall what you are doing is emulating SCSI disks for access by initiators on the SAN. So for each disk, one should be able to say things like: - Which initiators can access it. - Through which targets can the initiators access it. - What is the SCSI LUN number a given initiator sees when they access this disk. These setting are known as lun mappings. Also you should be able to specify the storage where the data for this emulated disk is stored. This can be a zvol, a file etc. This is known as backing store. Also even though you are specifying the LUN mappings for each lun, COMSTAR does not also you to specify initiators and targets individually. You have to specify a list of initiators and targets known as host groups and target groups (even if the list has only one member). So to put everything together: A LU is an actual emulated SCSI device (mostly a disk, but you can also emulate other SCSI devices like tape etc.). If the LU is a disk, then it needs a backing store which is mostly specified as a zvol (also known as volume). A target is simply an access point for an initiator to come in. When an initiator logs into a target, it sees a bunch of LUs depending upon the LUN mappings you specify. A view is simply another name for a single LUN mapping entry. Target portal group is an iSCSI construct. It is basically a way to tie in a bunch of IP addresses with an iSCSI target. I think it is described in COMSTAR Admin guide. But it is different from target group which is basically a list or targets which is then used
Re: [storage-discuss] test target test w/ QLA4010C ASA7211C
I was just comparing the login negotiated parameters from Andrew's captures for for the Qlogic Adaptec HBA cards: http://mail.opensolaris.org/pipermail/storage-discuss/2007-August/003187.html with those from the 'gpxe iscsi boot initiator' that Miro has posted in this thread: http://www.opensolaris.org/jive/thread.jspa?threadID=42154tstart=0 The login parameters from the gpxe initiator look even more minimal than those from the Qlogic adaptor! Qlogic was specifying InitialR2T=No and MaxRecvDataSegmentLength=65536 but the gpxe initiator is missing those out. How critical is that? Rick, are the minimum required parameter defined in the iscsi standard? Thanks Nigel Smith This message posted from opensolaris.org ___ storage-discuss mailing list storage-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/storage-discuss
Re: [storage-discuss] test target test w/ QLA4010C ASA7211C
Rick, I know you were able to get the Solaris iscsi target working with the Qlogic QLA4010C HBA. But Andrew was also trying the Adaptec ASA-7211c HBA, which was failing to work with the Solaris iscsi target in a different way. Andrew provided a capture file and I remember doing an initial analysis of it. Did you every get time to look at that capture or do any work with Andrew off-forum on the Adaptec card? Best Regards Nigel Smith This message posted from opensolaris.org ___ storage-discuss mailing list storage-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/storage-discuss
Re: [storage-discuss] test target test w/ QLA4010C ASA7211C
Jive has broken that URL link. Try this: http://www.opensolaris.org/jive/thread.jspa?messageID=143579 This message posted from opensolaris.org ___ storage-discuss mailing list storage-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/storage-discuss
Re: [storage-discuss] test target test w/ QLA4010C ASA7211C
Rick, I was curious to know what parameters the QLogic card was sending, so I went back to Andrews's original capture file, here: http://www.opensolaris.org/jive/thread.jspa?messageID=143579#143579 To document this issue in the forum, I have listed the values below. Best Regards Nigel Smith QLA4010c Initiator -- Solaris Target - Login InitiatorName=iqn.1996-05.com.prominic:host-307 TargetName=iqn.1986-03.com.sun:02:cd6dedbc-8291-ccf1-e938-89b74213a691 SessionType=Normal InitialR2T=No MaxRecvDataSegmentLength=65536 Solaris Target -- QLA4010c Initiator - Login Response TargetAlias=iscsi/host-307 TargetPortalGroupTag=1 InitialR2T=Yes MaxRecvDataSegmentLength=65536 This message posted from opensolaris.org ___ storage-discuss mailing list storage-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/storage-discuss
Re: [storage-discuss] test target test w/ QLA4010C ASA7211C
Rick, did you get a sponsor for this bug fix? I've been looking here: http://opensolaris.org/os/bug_reports/request_sponsor/ ..for an record, but I cannot find a match. Was a bug filed at http://bugs.opensolaris.org/ to track progress? Regards, Nigel Smith This message posted from opensolaris.org ___ storage-discuss mailing list storage-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/storage-discuss
Re: [storage-discuss] test target test w/ QLA4010C ASA7211C
No, I didn't get a sponsor. It was a simple fix and I gave it to Jim who said he would see that the changes where made. Maybe I need to go through the formal process since it's been almost two months. On 10/18/07, Nigel Smith [EMAIL PROTECTED] wrote: Rick, did you get a sponsor for this bug fix? I've been looking here: http://opensolaris.org/os/bug_reports/request_sponsor/ ..for an record, but I cannot find a match. Was a bug filed at http://bugs.opensolaris.org/ to track progress? Regards, Nigel Smith This message posted from opensolaris.org ___ storage-discuss mailing list storage-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/storage-discuss -- Rick McNeal A good friend will come and bail you out of jail ... but, a true friend will be sitting next to you saying, Damn .. that was fun! ___ storage-discuss mailing list storage-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/storage-discuss
Re: [storage-discuss] test target test w/ QLA4010C ASA7211C
In util.c there's a routine connection_parameters_default() which as the name implies contains default connection level parameters. Currently only the TPGT value was set. To fix this problem the following two lines need to be added. c-c_max_burst_len = 8192; c-c_data_pdu_in_order = True; As I stated, the Qlogic card sends the minimal about of information on login. Since it did not the c_max_burst_len was 0 and c_data_pdu_in_order was False (value of 0). The SAM layer would attempt to send the minimum of the transfer size or c_max_burst_len. Since it was zero the target would just spin. The other problem was for transfers that are larger than the Max Burst data is sent out in multiple PDUs. Asynchronous I/O requests complete in any order and send the DataIn PDU Order was false the iSCSI connection sent them out as it received them from the SAM layer. Qlogic rightfully dropped the connection when this occurred. I'll get a sponsor for these changes so that they can be put back into Solaris. On 8/23/07, Nigel Smith [EMAIL PROTECTED] wrote: Rick, that excellent news. It's good that, even though you no longer work at Sun, you can still find some spare time to help with these issues with the iscsi target. I'm curious to know what where the two missing parameter, that the target was not returning? And which routine need those extra two lines? Best Regards Nigel Smith This message posted from opensolaris.org ___ storage-discuss mailing list storage-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/storage-discuss -- Rick McNeal A good friend will come and bail you out of jail ... but, a true friend will be sitting next to you saying, Damn .. that was fun! ___ storage-discuss mailing list storage-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/storage-discuss
Re: [storage-discuss] test target test w/ QLA4010C ASA7211C
Nigel, You are correct. The dtrace provider was integrated in NV_69. More details are available here: http://blogs.sun.com/ahl/entry/iscsi_dtrace_provider_and_other Great analysis on the traces. We will take a look at them as well. -Ken On Aug 8, 2007, at 4:43 AM, Nigel Smith wrote: Ok, I'm curious to see what has happening here and so I have had a look at the capture files with Ethereal WireShark. First, lets look at 'solaris-qla4010c.cap'. Only 11 packets and the initiator is 192.168.1.100 and target is 192.168.1.10 The capture show the normal TCP handshake,then a Login from the initiator, and a successful login response from the target. Then in packet#9 the initiator send what Ethereal decodes as a 'SCSI: Test Unit Ready LUN: 0x00'. The target ACK's this packet, but there is then no further response from the target. After a 15 second delay the initiator RST's the connection. I notice that for the login and response, that the 'Initiator Task Tag' (ITT) is 0x00070001. But for packet#9, the ITT has changed to 0x000e0001 Ok, now let's look at 'solaris-asa7211c.cap'. 123 packets and again the initiator is 192.168.1.100 and target is 192.168.1.10 Again, this starts with the normal TCP handshake, followed by a login and success response. In packet#17, the initiator send what Ethereal decodes as a SCSI: Inquiry LUN: 0x00', with a CDB Opcode of 0x12. The target ACK's this packet, but there it then no further response from the target for 30 seconds, when the target send a 'NOP In' in packet#19. The initiator responded with a 'NOP Out'. The NOP'ing continues at 30 second intervals. The initiator then send a RST in packet#40. I notice that for the login and response, that the 'Initiator Task Tag' (ITT) is 0x00a96ca0. But for packet#17, the ITT has changed to 0x60ab6ca0. In packet#47, we kick off a further TCP handshake, followed by a login and success response. In packet#59, the initiator send what Ethereal decodes as a Text Command', with a Opcode of 0x04 and data of SendTargets=All The target ACK's this packet, but there is then no further response from the target for 180 seconds. Again, I notice that for the login and response, that the 'Initiator Task Tag' (ITT) is 0xa0b96ca0. But for packet#59, the ITT has changed to 0x00bc6ca0. The initiator then send a Logout to close the session and the target responds close successful. Then the whole sequence of packets is repeated again... Ok, I would not claim to be an expert on this, but my guess is that the target does not like the change in ITT and is ignoring the request from the initiator. Maybe someone who has a better understanding of RFC-3720 can jump in here and give an opinion. Oninoshi have a look at file /var/svc/log/system-iscsitgt \:default.log on the Solaris target and just check it's not showing process dumped core. Also Oninoshi, it would be interesting if you could provide some capture of the start of a successful iscsi boot for Centos and Windows, so that a comparison can be made between working and not-working traces. It seems to me that this is the sort of situation where it would be interesting to use the new DTrace iscsi provider to investigate what is happening. I think PSARC 2007/153 was suppose to be available in snv_69. Can someone confirm if this has happened? Thanks Nigel Smith This message posted from opensolaris.org ___ storage-discuss mailing list storage-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/storage-discuss Ken Davis - Manager Sun Microsystems New Solaris Storage Group work: 303.395.4168 cell: 720.837.5818 ___ storage-discuss mailing list storage-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/storage-discuss
Re: [storage-discuss] test target test w/ QLA4010C ASA7211C
no cores are being dumped (assuming it would show up in the svc log... I guess im new enough to Open Solaris I havent seen that happen) the only restarts were related to me restarting the service. I don't have a successful login capture at this time (or I would have included it). I do know we have clients using the qlogic card with hardware products (but I cant neither reboot a client machine randomly, nor sent a capture of client traffic). I will be demoing some commercial software targets later, so I'll get a capture and send it as soon as i can. Thank you A Hettinger This message posted from opensolaris.org ___ storage-discuss mailing list storage-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/storage-discuss
Re: [storage-discuss] test target test w/ QLA4010C ASA7211C
no cores are being dumped Ok, Good. It's just that core dumps were not that unusual earlier this year and people new to Solaris often did not realise to check for this. I don't have a successful login capture at this time Ok, I thought you had some initiators doing iscsi booting successfully with your EqualLogic iSCSI target... Thanks Nigel Smith This message posted from opensolaris.org ___ storage-discuss mailing list storage-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/storage-discuss
Re: [storage-discuss] test target test w/ QLA4010C ASA7211C
Have you tried this with the Solaris initiator? If you haven't, could you give it a try and send us a trace for that as well. and on the traces, I assume you were doing a normal send targets discovery? Were you trying to do a boot? Thanks Jeff A Hettinger wrote: no cores are being dumped (assuming it would show up in the svc log... I guess im new enough to Open Solaris I havent seen that happen) the only restarts were related to me restarting the service. I don't have a successful login capture at this time (or I would have included it). I do know we have clients using the qlogic card with hardware products (but I cant neither reboot a client machine randomly, nor sent a capture of client traffic). I will be demoing some commercial software targets later, so I'll get a capture and send it as soon as i can. Thank you A Hettinger This message posted from opensolaris.org ___ storage-discuss mailing list storage-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/storage-discuss ___ storage-discuss mailing list storage-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/storage-discuss
[storage-discuss] test target test w/ QLA4010C ASA7211C
I tested the iscsi target with the following HBAs: Adaptec ASA-7211c (which i trust about as far as i can throw adaptec... the company, not the card) QLogic QLA4010C (which i trust a bit more) Neither would detect my target, although I could see them come up if I monitored iscsitadm list target iscsi/host-307 Attached is a wireshark capture for each test. These tests were preformed on an isolated testing network, so there should be little extra traffic. The qla test is just a section that I saw repeating indefinitely. I'm afraid I dont know much about the iscsi protocol to have any more info then just that. This message posted from opensolaris.org solaris-qla4010c Description: Binary data solaris-asa7211c Description: Binary data ___ storage-discuss mailing list storage-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/storage-discuss
