Does moving a Clariion to another switch have an impact on HPUX host ?

having the same domain id does not mean that the host will get assigned the same fcid on the new switch. You can hard code fcid to a particular WWN on MDS. Once persistent FC ID feature is enabled on the VSAN and domain id is set to be the same as on the old switch ( domain part of fcid has to be identical) you can run:

config t

fcdomain fcid database

vsan 200 wwn 50:01:43:80:06:2f:6f:90 fcid 0x070128

I'm not moving the UX, I'm moving the Clariion. So does moving the Clariion to a new switch change anything for the UX ?

I mean, the FCID for the UX stays the same, but the one for the Clariion changes. Do I need to change something on the UX to be able to use my LUN's again ?

1. Device file names and iotree paths will change when a fabric switch replaces a loop.
   
   
2. Device file names and iotree paths will change when you move a target from one port on a fabric switch to another port on the switch.
   
   
3. Device files and iotree nodes will change if the switch domain changes.
   
   

Thank you, this explains it all

I know there are fundamental differences between HP-UX and AIX, but we see the same issues on both platforms (and ONLY these two operating systems). To provide the overly simple explanation of what we have seen in the past for these hosts:

• Move a Storage port (CLARiiON, Symm, etc.) and you will have to clean up the paths. The paths using that Storage port will be dead and you will find new paths created. Even with the AIX feature to dynamically switch paths you will still have to clean it up at some point.
  
• Move the host port and there is no effect - except for the obvious temporary interruption in I/O. I have heard this disputed before, but in our environment it has never caused any issue.
  

Man, I never would have thought running Windows in a SAN environemnt would be so much more attractive over other OSes

Windows just works if only we did not have to patch it every other Thursday.

Or run our critical applications on it

Windows / Powerpath and  SAN / Clariion/DMX is GREAT ! It's the OS itself that'shigh maintenance, but then again: it's relatively cheap in contrast to HPUX or IBM AIX. It's either this or that. Can't have it both ways. Hmmmmm.... Linux ! Cheap and great connectivity !

Hmmmmm.... Linux ! Cheap and great connectivity !

cheap but mediocre LVM compared to UX/AIX ...you just can't win

I agree RRR, I was mostly being sarcastic ;-)

I have been supporting Windows clusters on attached storage and then SAN attached storage since NT4. It has come a long way in that time and now is a fairly stable and reliable platform. It has gotten so much easier to manager SAN connectivity on Windows systems.

While I like my Windows servers (because I understand them to a greater extent than the Unix variants) I still agree that they have their issues. On the bright side, you don't have to wait a year to schedule an outage on them... cause they'll never last that long without a reboot anyway :-)

Really though, I still shudder when we have to do anything with the few Windows clusters we have in our environment. Part of this is because I never did any cluster work myself in my pre-storage server support days. We inherited some clusters with a company acquisition and now get to support them. The other reason they make me nervous is that they are so much more "touchy" when it comes to SAN connectivity, load balancing, failover, etc.

Hi,

There is a new feature in HP-UX 11i v3 called agile addressing (sometimes referred to as persistent lun binding). With this scheme, the h/w path is no longer encoded in the storage device path. This may be of interest.

Best regards, Richard.

It's kind of funny that they would name a feature based on "persistent binding" something like "agile addressing"! It sounds like some kind of oxymoron in development. In my mind agile and persistent imply two entirely differing perspectives, approaches, even philosophies.

I'm not discagreeing with you ion any way, just commenting on something that I find really odd and rather amusing :-)

Hello Allen,

I think the 'logic' is that we now have the agility for the h/w path to be able to change (eg. due to a change in the 24b FCID) , without us losing access to the LUN. Agile addressing is effectively persistently binding the LUN to the device path. Persistency is bound using the LUN's unique WWID.

The path format for agile addressing is: /dev/ disk/disk2  

(think of this path as pointing to the LUN's WWID).

Best regards, Richard.