PS6000 iSCSI SAN connectivity problem

[wirelessprom]

I am having issues with virtualizing a host that is set up via iSCSI to our SAN (PS6000) and was wondering if anyone has experienced similar issues. Now the problem is that when I try to even format the recognized disk from the SAN, it takes literally at least 5 hours to do a quick format. This morning there was broadcast storm on our standard production LAN, but for some reason this seemed to effect the traffic from one of our Hosts to the PS6000 on the iSCSI network.Can any one tell me that how do i resolve PS6000 iSCSI SAN connectivity problem? any one knows about it? Kindly help me out to resolve the above issue. Thanks.

[Milton.J]

iSCSI is a protocol that allows two hosts to send SCSI commands over a TCP/IP network. Sounds like you have done your due diligence with each vendor to try and diagnose the problem correctly. iSCSI uses TCP/IP (typically TCP ports 860 and 3260). In essence, iSCSI simply allows two hosts to negotiate and then exchange SCSI commands using IP networks. You can use SCSI but free yourself of the limitations of traditional SCSI cabling and, instead, use your LAN to connect your SCSI PCs and Server to your SCSI storage.

[Spyrus]

A separate DHCP server may be configured to assist interfaces equipped with network boot capability to be able to boot over iSCSI. iSCSI is a type of storage area network (SAN) and it is typically compared to Fibre Channel (FC) its much more expensive competitor. In this case the network interface looks for a DHCP server offering a PXE or bootp boot image. This is used to kick off the iSCSI remote boot process, using the booting network interface's MAC address to direct the computer to the correct iSCSI boot target.

[Snake08]

Rebooting a host sometimes causes the LUNs to show up, and sometimes causes other ones to disappear. Specialized iSCSI interfaces are available with built-in BIOS functionality that allows the interface to be preassigned to an iSCSI target, and be able to boot from it without additional help from a boot server, thereby reducing the network configuration complexity. Currently it seems to be that one of your host might be missing one LUN, and the other other can't see the SAN at all. You need to remove the iSCSI initiator, and then need to change the WWN, removing and recreating the ACLs on the SAN.

[Zachary]

Make sure your SCSI connected drives are hard coded to the Chapparel SCSI bridge. To ensure that only valid initiators connect to storage arrays, administrators most commonly run iSCSI only over logically-isolated backchannel networks. I have seen instances in the past where power glitches can cause the internal FCAL loops or SCSI busses to reset, thereby changing the ID of the connected drives.

[Big Fish]

Weird SAN issues such as you are seeing can be caused by error conditions by one member of your zone sets affecting the other members. While iSCSI can be logically isolated from the general network using VLANs only, it is still no different from any other network equipment and may use any cable or port as long as there is a completed signal path between source and target. The way to solve that problem is to make sure you are doing HBA zoning. HBA zoning means there is only a single initiator and target within each zone. Just a single cabling mistake by an inexperienced network technician can compromise the barrier of logical separation, and an accidental bridging may not be immediately detected because it does not cause network errors.