Hello,  On the vss-control volume, which is used my MS  Volume Shadow service to access Hardware snapshots, there is a CHAP username configured. however, the initiator is not sending a CHAP username/password..    If you are using the EQL HIT kit, then you should allow those servers access to that volume.  Or change the ACL on that volume to allow only those servers that need it, to access it.    You can also remove it from the favorites tab, so that it won't attempt to log in the next time the server boots up.  Finally, you can enable the Discovery filter to prevnet this from re-occuring.  Here's a KB from the Equallogic Website.  Solution Title Error: "Initiator wanted to skip security phase but we cannot." or "Initiator tried to bypass the security phase but we cannot."  Solution Details Symptom: Event log on the PS Array web interface shows a login error for a volume that says, "Initiator wanted to skip security phase but we cannot." This error may be repeated every few seconds continuously.  Issue: By default, volumes that have CHAP authentication enabled will be shown during the iSCSI discovery process even if the initiator doesn't have the CHAP credentials. Discovery is controlled by IP address ACLs, so if a machine matches an ACL's IP address field, we will see the volume. Note that many initiators such as ones that are unix based like the Cisco software initiator that VMWare uses will continue to attempt to login to that target (often, every two seconds) even though every login attempt fails. This can fill up the log, and can impact server performance.  Solution: Restrict the discovery of CHAP-authenticated volumes by IP address, and make sure that only the servers with the appropriate CHAP credentials can see the volume at all.  The most common volume to see this error on is the special volume named "vss-control." This volume is for communication with the Microsoft VSS service, using the EqualLogic Host Integration Tools. If it is configured for unrestricted access, or is configured for CHAP-only, then every initiator on the SAN will be able to discover it, and may attempt to use it. Set the "vss-admin" ACL to include an IP address for every machine that needs to access it, to ensure that no others do.  For firmware version 2.2.3 and before, go to the volume named "vss-control", select the Access tab, and change the entries there appropriately.  For firmware version 2.3.2 and later (including all 3.X releases), go to the Group Configuration area, and select the VSS/VDS tab. This is the ACL for the vss-control volume, which you should modify appropriately.  It may be necessary to reboot the servers that are trying to access this volume after changing the ACL, however. Some initiators do not release a target once they have discovered it, even if the array says that the target does not exist. One example of this are ESX servers using the software initiator.  A second scenario can be a volume which is setup to be seen from within a VMWare server Windows VM using CHAP credentials and also setup on the array to use a CHAP only login. Even though the CHAP credentials may be setup properly from each side if the ESX server is using the software initiator ESX will attempt to login to the volume continuously every so many minutes or seconds depending on various factors. With multiple volumes setup in this manner it can be a performance drain on ESX.  To solve this scenario make sure to enable the iSCSI Discovery Filter from within the PS Array GUI. This is done from the Group Configuration/iSCSI tab. Check the box off and save the configuration using the green disk icon in the upper right corner of the GUI. Once this is done only servers with initiators that are properly setup to see a volume with CHAP will see and attempt to login to those volumes. Note: Once an ESX server has seen a volume it will keep trying to login with the software initiator until the ESX server is restarted after this option is enabled.  Note that, starting with firmware version 3.0.5 and later, you can require authentication for CHAP-enabled volumes during discovery, by issuing the command from the CLI:  GroupName> grpparams discovery-use-chap enable   Regards, 
Hi, I started working on new company and tonight we lost storage for about an hour and errors came: ERROR event from storage array SAN1subsystem: MgmtExec    event: 7.4.3    time: Sun Apr 21 00:58:18 2013iSCSI login to target '10.10.10.21:3260, iqn.2001-05.com.equallogic:4-52aed6-cb0bdf198-eee0000000c50212-vss-control' from initiator '10.10.10.22:53396, iqn.1991-05.com.microsoft:sp2-vm-sql2.company.local' failed for the following reason:Initiator tried to bypass the security phase but we cannot. On windows this night first errors started: EventID: 4025Source: EqualLogiciSCSI login error 0xefff0009 when connecting to vss-control volume for group 10.10.10.41 EventID: 10Source: iScsiPrtLogin request failed. The login response packet is given in the dump data. These errors I see repeating from the past in Windows event log.  This is hyper-v virtual SQL cluster with iSCI Dell storage connection.  How to solve this? thanks
Error: Initiator tried to bypass the security phase but we cannot