cfgadm and Hitachi Storage - SUN

This is a discussion on cfgadm and Hitachi Storage - SUN ; Is there a way to remove individual Hitachi Tagmastore or 9900-based LUNs from Solaris via `cfgadm`? Since the Hitachi arrays present *all* of the LUNs via a common WWN, it doesn't seem there's a way to give `cfgadm` a unique ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: cfgadm and Hitachi Storage

  1. cfgadm and Hitachi Storage

    Is there a way to remove individual Hitachi Tagmastore or 9900-based LUNs
    from Solaris via `cfgadm`? Since the Hitachi arrays present *all* of the
    LUNs via a common WWN, it doesn't seem there's a way to give `cfgadm` a
    unique target to unconfigure (and can't very well nuke the entire WWN since
    other, active LUNs are also on that WWN). Thus, when the SAN administrators
    de-zone LUNs from a running system, Solaris "remembers" the devices but
    `format` shows them as offline/not available until the next reboot. It
    would be aesthetically preferable if they could be completely deleted when
    the LUNs are de-zoned from the system (without having to reboot). So, is
    there something fun-duh-mental that I'm overlooking, here? I don't recall
    having this issue on storage subsystems that present LUNs with unique WWNs.
    --

    "You can only be -so- accurate with a claw-hammer." --me

  2. Re: cfgadm and Hitachi Storage

    In comp.sys.sun.admin Thomas H Jones II wrote:
    > Is there a way to remove individual Hitachi Tagmastore or 9900-based LUNs
    > from Solaris via `cfgadm`? Since the Hitachi arrays present *all* of the
    > LUNs via a common WWN, it doesn't seem there's a way to give `cfgadm` a
    > unique target to unconfigure (and can't very well nuke the entire WWN since
    > other, active LUNs are also on that WWN). Thus, when the SAN administrators
    > de-zone LUNs from a running system, Solaris "remembers" the devices but
    > `format` shows them as offline/not available until the next reboot. It
    > would be aesthetically preferable if they could be completely deleted when
    > the LUNs are de-zoned from the system (without having to reboot). So, is
    > there something fun-duh-mental that I'm overlooking, here? I don't recall
    > having this issue on storage subsystems that present LUNs with unique WWNs.


    are you running devfsadm after cfgadm to remove the disks that aren't
    there anymore?

    - san/zoning change stuff
    - cfgadm -al
    - devfsadm -Cv
    - run format and look again.

  3. Re: cfgadm and Hitachi Storage

    In article ,
    Cydrome Leader wrote:
    >are you running devfsadm after cfgadm to remove the disks that aren't
    >there anymore?
    >
    >- san/zoning change stuff
    >- cfgadm -al
    >- devfsadm -Cv
    >- run format and look again.


    Yup. Run through the whole gamut. Problem seems to be that, because the
    Hitachis aren't presenting the LUNs down unique WWNs, cfgadm isn't properly
    'disconnecting' the absent LUN/device after a de-zone. Thus, reruning
    `devfsadm -C` doesn't seem to accomplish anything.
    --

    "You can only be -so- accurate with a claw-hammer." --me

  4. Re: cfgadm and Hitachi Storage

    On Nov 23, 8:12 pm, fer...@xanthia.com (Thomas H Jones II) wrote:
    > In article ,
    > Cydrome Leader wrote:
    >
    > >are you running devfsadm after cfgadm to remove the disks that aren't
    > >there anymore?

    >
    > >- san/zoning change stuff
    > >- cfgadm -al
    > >- devfsadm -Cv
    > >- run format and look again.

    >
    > Yup. Run through the whole gamut. Problem seems to be that, because the
    > Hitachis aren't presenting the LUNs down unique WWNs, cfgadm isn't properly
    > 'disconnecting' the absent LUN/device after a de-zone. Thus, reruning
    > `devfsadm -C` doesn't seem to accomplish anything.
    > --
    >
    > "You can only be -so- accurate with a claw-hammer." --me


    Before depresenting the san disk you need to give each path (or the
    single mpxio path) a luxadm -e offline .

    Your servers may or may be at risk of crashing right now that there
    are missing luns. You may want to schedule reboots to clear that up.
    Alternatively, you may be able to get around if you can present new
    luns in such a way that they show up with exactly the same path, and
    then offline it as above.

  5. Re: cfgadm and Hitachi Storage

    In comp.sys.sun.admin Thomas H Jones II wrote:
    > In article ,
    > Cydrome Leader wrote:
    >>are you running devfsadm after cfgadm to remove the disks that aren't
    >>there anymore?
    >>
    >>- san/zoning change stuff
    >>- cfgadm -al
    >>- devfsadm -Cv
    >>- run format and look again.

    >
    > Yup. Run through the whole gamut. Problem seems to be that, because the
    > Hitachis aren't presenting the LUNs down unique WWNs, cfgadm isn't properly
    > 'disconnecting' the absent LUN/device after a de-zone. Thus, reruning
    > `devfsadm -C` doesn't seem to accomplish anything.


    Interesting. I'll have to add that to list of stupid things solaris does
    need a reboot for.

+ Reply to Thread