HPE EVA Storage
1826811 Members
3245 Online
109704 Solutions
New Discussion

No vgreduce/vgextend on SAN fabric Change

 
Sam_120
Occasional Contributor

No vgreduce/vgextend on SAN fabric Change

A customer of mine recently changed fabrics on his HP-UX host. The storage port and the hba port both changed, as well as the DomainID and port number on the switch. I was previously told that HP-UX binds to the domain ID and port of the switch and that if they ever changed, he would have to vgreduce/vgextend for each path.
The customer expected this to happen on a recent cut-over but did not have to do any changes other than use powerpath to bring the path back online.
All the volumes were accounted for without any changes even after a storage and hba port were moved to different devices with different port numbers and domain ID's
Does anyone know why? Was there a specific HP patch that fixed that issue?
Cheers,
2 REPLIES 2
Gert Greyling
New Member

Re: No vgreduce/vgextend on SAN fabric Change

Same experience. Had to backup data and recreate my volumes, although SAM reported the new sizes I could not extend the volume.
Uwe Zessin
Honored Contributor

Re: No vgreduce/vgextend on SAN fabric Change

Sam,
I assume you know that EMC's Powerpath or HP's Secure Path are additions to the operating system to give it multi-path capability with certain storage arrays.

Technically they come with a 'filter driver' that gets hold of all storage array device entries (all paths of all LUNs). It creates a new set of 'pseudo devices' (one for each LUN) which the user can access. The filter driver will 'pass on' one of the real devices of a LUN to the pseudo device and select another real device if the current one becomes unavailable.

Well, I have simplified things a little but, but I think you get the idea. A graphical representation is at pages 17 and 21 of the following manual:
http://h20000.www2.hp.com/bizsupport/CoreRedirect.jsp?targetPage=http%3A%2F%2Fh200005.www2.hp.com%2Fbc%2Fdocs%2Fsupport%2FUCR%2FSupportManual%2FTPM_aa-rr4ve-te%2FTPM_aa-rr4ve-te.pdf

So the volume manager was still working with the same set of 'pseudo devices' and the multipath software 'somehow' managed to assign the new device paths to the same pseudo devices (persistent LUN binding).


Gert,
it looks to me like you and Sam are talking about completely different things:

- Sam is talking about changes to the fabric that result in a different
hardware path to the LUNs

- you are talking about expanding the size of a LUN. Last time I checked that is not supported by HP-UX. You must create a new LUN, make a new physical volume and add it to the volume group in question.
.