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

In comp.sys.sun.admin Thomas H Jones II <ferric@xanthia.com> 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.

In article <fi7pmu$j9s$4@reader1.panix.com>,
Cydrome Leader <presence@MUNGEpanix.com> 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

On Nov 23, 8:12 pm, fer...@xanthia.com (Thomas H Jones II) wrote:
> In article <fi7pmu$j9...@reader1.panix.com>,
> Cydrome Leader <prese...@MUNGEpanix.com> 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 <raw disk device>.

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.

In comp.sys.sun.admin Thomas H Jones II <ferric@xanthia.com> wrote:
> In article <fi7pmu$j9s$4@reader1.panix.com>,
> Cydrome Leader <presence@MUNGEpanix.com> 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.