This may sound like a foolish question, but are you sure the iSCSI target is still assigned to /dev/sda on the initiator? If you haven't done so, run fdisk -l and see if the LU isn't attached somewhere else now. I've had this issue on my Linux setups and have yet to track down why the iSCSI initiator (or possible the SCSI framework itself) will not reassign the device to the same dev name.
On Thu, Jan 22, 2009 at 11:32 AM, Eric Sproul <[email protected]> wrote: > Hi, > I hope this isn't a FAQ (Google has been of little help so far). I've set up > a > pair of virtual machines to test a SAN implementation. I'm fairly new to > iSCSI > but have a working understanding of it. The VMs are running under VirtualBox > 2.1.2 (they were 2.1.0 before today). The target server is running SXCE b105, > exporting a 500MB zvol (zfs set shareiscsi=on). The initiator is running > CentOS > 5, fully updated. I'm using the following initiator version: > iscsi-initiator-utils-6.2.0.868-0.7.el5 > > I've set up all the VMs with host interface networking on top of Crossbow > vnics, > and everything worked fine initially-- I used static iSCSI configuration to > add > the node and establish a session to the server. The initiator host saw > /dev/sda, which I was able to partition and format /dev/sda1 with ext3. I was > able to reboot the initiator host and have it reestablish the session (it did > not automatically mount the device, even though it was in the fstab, but I > don't > think that's relevant here.) > > The problem started upon rebooting the target server (I had already > disconnected > the iSCSI session.) Subsequent attempts to mount the device on the initiator > are met with "mount: special device /dev/sda1 does not exist". The initiator > successfully logged in and set up a session, but it appears that when it does > the LUN inquiry, it gets a "check condition" (0x02) response. I have a pcap > file of the session if anyone is interested. There doesn't seem to be > anything > amiss at the IP layer. > > I can see nothing wrong with the server end. The zpool has no errors (I've > scrubbed it to make sure), and I can see the active share: > # iscsitadm list target > Target: data/vol/testlun1 > iSCSI Name: iqn.1986-03.com.sun:02:30ee529b-2f66-e78d-92f1-b32b39307ed6 > Connections: 1 > > Here is my session info on the intiator: > # iscsiadm -m session -P 1 > Target: iqn.1986-03.com.sun:02:30ee529b-2f66-e78d-92f1-b32b39307ed6 > Current Portal: 10.254.116.2:3260,1 > Persistent Portal: 10.254.116.2:3260,1 > ********** > Interface: > ********** > Iface Name: default > Iface Transport: tcp > Iface Initiatorname: iqn.1994-05.com.redhat:625c1ee744 > Iface IPaddress: 10.254.116.4 > Iface HWaddress: default > Iface Netdev: default > SID: 1 > iSCSI Connection State: LOGGED IN > iSCSI Session State: Unknown > Internal iscsid Session State: NO CHANGE > > Are there any common causes of LUN errors like this? How do I get iscsitgtd > to > give me some logs? Also, based on my (admittedly thin) understanding of SCSI > protocol, an initiator should follow up a check condition with a request sense > to discover the nature of the error, and I don't see that happening here. > Anyone know how I could trigger that to happen? > > Thanks, > Eric > _______________________________________________ > storage-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/storage-discuss > -- Rick McNeal "Democracy is two wolves and a sheep voting on what to have for lunch. Liberty is a well armed sheep contesting the vote." Benjamin Franklin _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
