Re: Rescan LUNs hangs
16:0:0:5: [sdag] Asking for cache data failed Jul 14 23:10:39 cpu03 kernel: sd 16:0:0:5: [sdag] Assuming drive cache: write through Jul 14 23:10:39 cpu03 kernel: sd 16:0:0:7: [sdai] Unit Not Ready Jul 14 23:10:39 cpu03 kernel: sd 16:0:0:7: [sdai] Sense Key : Illegal Request [current] Jul 14 23:10:39 cpu03 kernel: sd 16:0:0:7: [sdai] Add. Sense: Logical unit not supported Jul 14 23:10:39 cpu03 kernel: sd 16:0:0:7: [sdai] READ CAPACITY(16) failed Jul 14 23:10:39 cpu03 kernel: sd 16:0:0:7: [sdai] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Jul 14 23:10:39 cpu03 kernel: sd 16:0:0:7: [sdai] Sense Key : Illegal Request [current] Jul 14 23:10:39 cpu03 kernel: sd 16:0:0:7: [sdai] Add. Sense: Logical unit not supported Jul 14 23:10:39 cpu03 kernel: sd 16:0:0:7: [sdai] READ CAPACITY failed Jul 14 23:10:39 cpu03 kernel: sd 16:0:0:7: [sdai] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE Jul 14 23:10:39 cpu03 kernel: sd 16:0:0:7: [sdai] Sense Key : Illegal Request [current] Jul 14 23:10:39 cpu03 kernel: sd 16:0:0:7: [sdai] Add. Sense: Logical unit not supported Jul 14 23:10:39 cpu03 kernel: sd 16:0:0:7: [sdai] Test WP failed, assume Write Enabled Jul 14 23:10:39 cpu03 kernel: sd 16:0:0:7: [sdai] Asking for cache data failed Jul 14 23:10:39 cpu03 kernel: sd 16:0:0:7: [sdai] Assuming drive cache: write through Jul 14 23:10:39 cpu03 kernel: sd 18:0:0:2: [sdan] Unit Not Ready Jul 14 23:10:39 cpu03 kernel: sd 18:0:0:2: [sdan] Sense Key : Illegal Request [current] Jul 14 23:10:39 cpu03 kernel: sd 18:0:0:2: [sdan] Add. Sense: Logical unit not supported Jul 14 23:10:39 cpu03 kernel: sd 18:0:0:2: [sdan] READ CAPACITY(16) failed Jul 14 23:10:39 cpu03 kernel: sd 18:0:0:2: [sdan] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE skip lots of these Jul 24 16:51:30 cpu03 kernel: scsi 24:0:0:5: Direct-Access IET VIRTUAL-DISK 0001 PQ: 0 ANSI: 5 Jul 24 16:51:30 cpu03 kernel: sd 24:0:0:5: Attached scsi generic sg142 type 0 Jul 24 16:51:30 cpu03 kernel: scsi 29:0:0:5: Direct-Access IET VIRTUAL-DISK 0001 PQ: 0 ANSI: 5 Jul 24 16:51:30 cpu03 kernel: sd 29:0:0:5: Attached scsi generic sg143 type 0 Thanks for any insight you can provide! -- Tracy Reed pgpTyVBc5sJ2Y.pgp Description: PGP signature
Rescan LUNs hangs
Hello all, I am running iscsi-initiator-utils-6.2.0.872-13.el5 on CentOS release 5.4 (will patch up at next reboot) initiator to scsi-target-utils-1.0.24-2.el6.x86_64 on CentOS 6.4. I have Xen running on the initiator machine with luns from the target machine as storage. I actually have two target machines and do software raid1 in the VMs. I needed to upgrade one of the target machines so I split the mirrors in the VMs and shutdown the target machine, upgraded some disk, reinstalled new OS etc. Now when I do /sbin/iscsiadm -m node -R on the initiator machine it hangs. The process seems uninterruptable. I can't kill -9 it and it spins using 100% of a cpu. I think perhaps before I shutdown the target machine I should have logged out the initiator from it. Now I have a bunch of hung processes and I can't access new disk volumes because I can't rescan the LUNs. How do I clear this up, preferably without rebooting the initiator? Thanks! -- Tracy Reed pgpx6y9bQAXNc.pgp Description: PGP signature
Re: Can't discover new targets
On Thu, Jul 12, 2012 at 11:52:31AM PDT, Mike Christie spake thusly: So you did not have to run: tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL the ACL information section in the tgtadm -op show command said ALL by default? If so that is all that is needed for simple setup that allows any initiators access. I thought before you had to run the above command for each target when setting them up with tgtadm by hand. Ah-hah No, I never ran that command. But I bet during my messing about with tgt-admin it got run and I didn't realize it and that is how I could access the first target. I just ran that command for my undiscoverable target and the initiator successfully discovered it. So it seems that when adding targets manually I need to explicitly set the ACL to ALL. I'll check with the tgt-admin guys about why my tgt-admin --dump isn't returning anything. Thanks a lot for the help! -- Tracy Reed pgpL6gzZWd7yP.pgp Description: PGP signature
Re: Can't discover new targets
On Wed, Jul 11, 2012 at 09:50:17PM PDT, Mike Christie spake thusly: I have not run tgtadm manually for a while but I think you need to also set the ACL for that target? I never had to do anything along these lines for the other targets I have set up... If you just add the targets and luns to /etc/tgt/targets.conf then run service tgtd start does it work? I think the default for that is to just allow any initiator to login without chap so that should work. For a while I was confused as to the difference between tgt-admin and tgtadm. I'm surprised such confusing names were chosen. Just to make sure I've got it straight: tgtadm manually sets up the targets and LUNs and tgt-admin reads/writes the targets.conf config file. The iSCSI HOWTO's for CentOS that I have found all seem to use tgtadm to set things up manually so that is what I have been doing. Since I have recently found out about tgt-admin I have been doing tgt-admin --dump on my iSCSI target machines so I can write out the targets.conf to persist the configs. But when I do tgt-admin --dump I get no output. As if it has nothing configured. But if I do: tgtadm --lld iscsi --mode target --op show I get output as described before showing that targets and LUNs are configured. So...I'm not sure what is going on here. How are target and LUN numbers assigned in targets.conf? I don't see any assigned. I have a feeling they are assigned by order in the config file but that seems risky as you could add a line or stanza and cause everything to shift. One thing I'm wondering about is if it is necessary to have all of the targets assigned sequentially and for the targets to all have LUNs on them. For example I have target 1 with LUN1 then I have targets 2 and 3 with no LUNs and then target 4 with the LUN that I am trying to discover. The fact that targets 2,3 don't have any LUNs doesn't matter does it? Thanks! -- Tracy Reed pgpEpoGsmAiHG.pgp Description: PGP signature
Can't discover new targets
Hello all! I added a target and LUN as I've done before using iscsiadm but when I do sendtargets on the initiator this time the new target is not listed. I do see the old target I created weeks ago. The initiator is CentOS 6.2 with iscsi-initiator-utils-6.2.0.872-34.el6.x86_64 and the target is CentOS release 5.8 with scsi-target-utils-1.0.14-2.el5. The existing target/LUN work perfectly so I expect so. I can set up the target: # /usr/sbin/tgtadm --lld iscsi --op new --mode target --tid 4 -T iqn.2012-04.com.mydomain.disk01:1d and the LUN: # /usr/sbin/tgtadm --lld iscsi --op new --mode logicalunit --tid 4 --lun 1 -b /dev/diskd/backup-md10 and I know the above commands worked as intended because I can do: # /usr/sbin/tgtadm --lld iscsi --mode target --op show and get: Target 4: iqn.2012-04.com.mydomain.disk01:1d System information: Driver: iscsi State: ready I_T nexus information: LUN information: LUN: 0 Type: controller SCSI ID: IET 0004 SCSI SN: beaf40 Size: 0 MB, Block size: 1 Online: Yes Removable media: No Readonly: No Backing store type: null Backing store path: None Backing store flags: LUN: 1 Type: disk SCSI ID: IET 00040001 SCSI SN: beaf41 Size: 237297 MB, Block size: 512 Online: Yes Removable media: No Readonly: No Backing store type: rdwr Backing store path: /dev/diskd/backup-md10 Backing store flags: Account information: ACL information: But on the initiator I only see my existing target and not target 2 LUN 4: # iscsiadm --mode discovery --type sendtargets --portal disk01 10.0.1.3:3260,1 iqn.2012-03.com.mydomain.disk01:1c Anyone have any ideas where I'm going wrong here? Thanks! -- Tracy Reed pgpFaSEBuobyE.pgp Description: PGP signature
Re: list of targets that support ERL1
On Mon, Jan 05, 2009 at 12:38:49PM -0800, Albert Pauw spake thusly: On Jan 5, 7:26 pm, Ming Zhang blackmagic02...@gmail.com wrote: On Mon, 2009-01-05 at 12:10 -0600, Mike Christie wrote: Hey Target vendors and Users, If you know of a target that supports ERL1, could you email me? Do it off list or on the thread. It does not matter. http://linux-iscsi.org/index.php/Main_Page The Wasabi Storagebuilder target supports ERL0, 1, and 2 according to their documentation. What does ERL 1 or 2 really buy you? ERL 0 just means re-establishing the connection right? This can't take very long. And how often do errors happen? I've read the RFC's and it seems like supporting 1 and 2 are a lot of complication for little gain. But maybe I'm missing something. I have looked and I am not aware of any FOSS target that supports ERL1 or 2. -- Tracy Reed http://tracyreed.org pgp36zznB8u8u.pgp Description: PGP signature
Re: Linux iscsi performance, multipath issue
On Wed, Dec 10, 2008 at 05:38:15PM -0800, fuubar2...@yahoo.com spake thusly: SuSE 10 and SuSE10w/SP1 install a kernel below 2.6.17. If your kernel is 2.6.16 or less, then the following kernel tuning variables may help Just out of curiosity, what changed after 2.6.16 which makes these variables irrelevant? I still set these even on modern kernels but perhaps I am wasting my time. -- Tracy Reed http://tracyreed.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups open-iscsi group. To post to this group, send email to open-iscsi@googlegroups.com To unsubscribe from this group, send email to open-iscsi+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/open-iscsi -~--~~~~--~~--~--~---
