Re: Target Reset

["John Hufferd" <hufferd@us.ibm.com>]

Eddy,
A target like an IBM Shark or EMC Symmetrix will have thousands of LUs and
10s to 100s of Hosts connected to it, and you want to reset the whole
Target?  I do not think that is a good idea.  Perhaps Task Reset or LU
reset etc. but not Target Reset.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Internet address: hufferd@us.ibm.com


"Eddy Quicksall" <ESQuicksall@hotmail.com> on 04/23/2001 09:44:05 AM

To:   "Dillard, David" <david_dillard@adaptec.com>, John Hufferd/San
      Jose/IBM@IBMUS
cc:   <ips@ece.cmu.edu>
Subject:  Re: Target Reset



I am wondering how clustering will work on NT without some sort of reset.

On parallel SCSI, NT will issue a SCSI BUS RESET to break reservations
during a challenge for the quorum drive.

On iSCSI, there is no full equivalent to the SCSI BUS RESET so I would
assume the NT driver would have to issue a TARGET RESET to each target that
it is supporting.

How would you propose this would be done without a TARGET RESET?

Eddy

----- Original Message -----
From: "John Hufferd" <hufferd@us.ibm.com>
To: "Dillard, David" <david_dillard@adaptec.com>
Cc: <ips@ece.cmu.edu>
Sent: Sunday, April 22, 2001 3:20 PM
Subject: RE: Target Reset


>
> This is at least better.  But I do not have the issue of it being vendor
> unique.  This is a shut down and restart of the complete Target, and will
> probably be part of the vendors' operator console or their own remote
> support functions, it is not clear that it needs to be a general
management
> function that works the same on all iSCSI Storage Controllers.
>
> Many of the major Storage Controller do not support this feature today.
>
> I do not believe that most SNMP implementations are very secure.  Most
> folks do not want to have a changeable MIB until they have secure SNMP,
and
> even though there is a version of SNMP that has security features, this
has
> not been well supported.
>
> I do NOT think that Target Reset should be in the base iSCSI protocol,
but
> I think it is reasonable to hold this discussion apart from the base
> protocol document, and the question should be asked if this is a general
> management function or a vendor specific console or remote support
> function.
>
>
>
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Internet address: hufferd@us.ibm.com
>
>
> "Dillard, David" <david_dillard@adaptec.com>@ece.cmu.edu on 04/22/2001
> 08:13:49 AM
>
> Sent by:  owner-ips@ece.cmu.edu
>
>
> To:   ips@ece.cmu.edu
> cc:
> Subject:  RE: Target Reset
>
>
>
> John,
>
> I understand the danger of issuing a target reset and I agree that it
> should
> not be a part of the an initiator's normal error recovery procedure.
> However, looking at this from a management perspective I'd like to see a
> standardized way of resetting a target.  I don't want to see a variety of
> vendor unique methods of resetting targets sprout up.
>
> If resetting a target using the protocol is not desirable from your
> perspective would incorporating this feature into the MIB be acceptable?
> (MIBs are for management after all)
>
> ----------------------------------------------------------------
> David Dillard                          david_dillard@adaptec.com
> Management Software Group
> Adaptec, Inc.                          www.adaptec.com
>
>
>
>
> -----Original Message-----
> From: John Hufferd [mailto:hufferd@us.ibm.com]
> Sent: Sunday, April 22, 2001 4:59 AM
> To: ips@ece.cmu.edu
> Subject: Target Reset
>
>
> I thought we had a number of discussion previously about Target Reset
(Warm
> or Cold).  I thought there was general feeling that this command is so
> dangerous that it should not be supported by iSCSI.  The long distance
> capability of iSCSI makes the risks involved unmanageable.  There should
> only be an Admin way to do this.
>
> Some folks have said that we could permit it and have special
authorization
> etc.  This would probably cause a separate section in the spec. to define
> the authorization approach,  and what ever other security is needed to
> prevent this from inappropriately being used.  All for what purpose?
This
> can not be part of error recovery from a normal initiator.  The wide
spread
> effect is too great for that.
>
> I would like to hear from the list about their feeling on this item.
>
>
>
> .
> .
> .
> John L. Hufferd
> Senior Technical Staff Member (STSM)
> IBM/SSG San Jose Ca
> (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
> Internet address: hufferd@us.ibm.com
>
>
>
>