We have noticed if I ssh into XenServer and delete the file /etc/iscsi/ 10.10.8.108,3260 (where 10.10.8.108 is our storage's IP address and 3260 is the port) that I can create SRs using different CHAP credentials.
Can anyone think of a "got-cha" here? Thanks! On Wed, Dec 18, 2013 at 3:18 PM, Tim Mackey <tmac...@gmail.com> wrote: > Mike, > > I'm referring to the open-iscsi code used by XAPI. XAPI has a storage > manager API which deals with all the SR management. It's also where the > issue you're running into exists. > > In terms of clearing the connections and credentials, the easiest way is > via a reboot. Since your using multiple CHAP credentials, only one set > will be used and any SRs which use a different CHAP secret will fail to > have their targets discovered during the pdb-plug phase of storage > initialization. You can then destroy the SRs which failed to come up and > move forward. > > -tim > > > On Wed, Dec 18, 2013 at 4:35 PM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > > > Hey Tim, > > > > When you refer to modifying the storage manager, are you referring to > > CloudStack? > > > > Perhaps you are referring to CitrixResourceBase, which is where we > discover > > and log in to iSCSI targets. > > > > Do you know of a way to delete those cached CHAP credentials via XAPI so > > when new ones are used for discovery they can work? > > > > Thanks! > > > > > > On Wed, Dec 18, 2013 at 2:22 PM, Tim Mackey <tmac...@gmail.com> wrote: > > > > > Unfortunately what you're experiencing is how it works. While > XenServer > > > does support different CHAP credentials by SR, it only supports a > single > > > CHAP credential for discovery. It can be made to work, but you'd need > to > > > either modify how the storage manager works to pull it off, or rewrite > > some > > > of the init scripts to cache the discovery data. > > > > > > > > > On Wed, Dec 18, 2013 at 3:55 PM, Mike Tutkowski < > > > mike.tutkow...@solidfire.com> wrote: > > > > > > > Hi, > > > > > > > > I just noticed a problem today while creating SRs in XenServer. > Perhaps > > > > someone with related experience could point me in the right > direction. > > > > > > > > Let's say my SAN's management IP address is X. > > > > > > > > I can have XenServer create a shared SR using IP address X with CHAP > > > > credentials Y. > > > > > > > > If I try to have XenServer create another shared SR using IP address > X > > > that > > > > uses different CHAP credentials (ex. CHAP credentials Z), XenServer > > > returns > > > > a discovery failure. > > > > > > > > It's like XenServer is expecting all iSCSI targets at the same IP > > address > > > > to have the same CHAP credentials. > > > > > > > > Does anyone know if I am mistaken here? This seems like a critical > > defect > > > > if this is true. > > > > > > > > Thanks! > > > > > > > > -- > > > > *Mike Tutkowski* > > > > *Senior CloudStack Developer, SolidFire Inc.* > > > > e: mike.tutkow...@solidfire.com > > > > o: 303.746.7302 > > > > Advancing the way the world uses the > > > > cloud<http://solidfire.com/solution/overview/?video=play> > > > > *™* > > > > > > > > > > > > > > > -- > > *Mike Tutkowski* > > *Senior CloudStack Developer, SolidFire Inc.* > > e: mike.tutkow...@solidfire.com > > o: 303.746.7302 > > Advancing the way the world uses the > > cloud<http://solidfire.com/solution/overview/?video=play> > > *™* > > > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
