pvlinks, not failing back to primary when ok, and set correctly

[generic_1]

Anyone seen problems in 11i that cause pvlinks not to fail back to the primary on their own, obviously assuming you have it setup that way.

I am looking for patches and notes that say they actually fixed this particular problem.

No blind links to patches patches in general please :).

Many thanks. Curious if anyone has seen this or documented cases. Thanks.

[Sudeesh]

I have few questions for you:

1. Is it a SG environment?
2. Are you facing this issue in a shared VG?

In addition can you pls post the exact version of HPUX (uname -a) and patch level.

Sudeesh

[generic_1]

1. One server is and one server isnt. I think its just a bug with pvlinks

2. It's 11i, I dont think the group has kept up on patching. I am just looking for specific fixes and descriptions that apply to pvlinks failback problems

I am just looking for patch fixes that address my question, not a general patching plan.

[Pete Randall · Accepted solution]

Jeff,

A quick search in the patch database on "pvlinks" brought up the following patches:

PHCO_30850 s700_800 11.11 VxVM 3.5m Command Cumulative Patch 07

PHCO_28378 s700_800 11.11 VxVM B.03.20.1 Command Cumulative Patch 03

PHKL_26743 s700_800 11.11 LVM Cumulative Patch

PHKL_32090 s700_800 11.11 SCSI IO Cumulative Patch

If you're not using VxVM, that narrows it down to two that might apply to you:

http://www2.itrc.hp.com/service/patch/patchDetail.do?BC=patch.breadcrumb.main|patch.breadcrumb.search|&patchid=PHKL_26743&context=hpux:800:11:11

-and-

http://www2.itrc.hp.com/service/patch/patchDetail.do?BC=patch.breadcrumb.main|patch.breadcrumb.search|&patchid=PHKL_26743&context=hpux:800:11:11


Pete

[Steven E. Protter]

Once tested, I've never seen PVLINKS have that problem.

Poking through Pete's post tells me if you are LVM he may have found the patch.

You may however have a situation that HP has not done a patch for, therefore necessitating the need for a response center call and HP to punch out a patch for you.

You have these issues in testing?

SEP

[James R. Ferguson]

Hi Jeff:

Make sure that you have 'autoswitch' enabled. You can check this by doing:

# vgdisplay -v vgNN

Look for the autoswitch status under the physical volmes output.

To set/reset the behavior, use 'pvchange':

# pvchange -S y|n pv_path

See the manpages for 'vgdisplay' and 'pvchange' for more information.

Regards!

...JRF...

[Torsten.]

Jeff,

I'm sure this is related to the new LVM features (LVM_OLR) introduced with PHKL_31216 and PHCO_30698 (11i v1) or PHKL_32095 and PHCO_31709 (11i v2). Found your scenario in PHKL_32854 patch description:

HP advises not to remove patches PHKL_31216 and PHKL_32854 unless there is an absolute need for switching back to the preferred path. There is no loss of availability, and LVM will switch back to the preferred path should the alternate path become unavailable.

Regards
Torsten

[generic_1]

The disks in the affected volume groups do have autoswitch on.

I noticed that my primary pathes on one of the systems are my seconday listed first in the /etc/lvmtab. Just one of the systems. When a system boots is the first path listed always the primary and is there way to fix this easily? Hopefully without outage.

[James R. Ferguson]

Hi Jeff:

The order of appearance of the paths in /etc/lvmtab dictates the primary versus secondary.

Yes, you can easily demote and promote a pvlink. Simply do:

# vgreduce /dev/vgNN pv_path #...current primary
# vgextend /dev/vgNN pv_path #...old primary

The 'vgreduce' causes the current primary link to be removed, promoting the alternate (secondary) link to be the new primary. The 'vgextend' then adds the old primary path back as the new secondary one.

Regards!

...JRF...

[James R. Ferguson]

Hi (again) Jeff:

If you did a 'vgimport' of your volume group with the '-s' option, it is very possible that the original order of your pvlinks was changed.

If you (ever) do a 'vgscan' it is likely that the order of physical links will change.'

Having said that, in addition to re-ordering pvlinks by doing 'vgreduce/vgextend' paired operations, you can 'vgexport/vgimport' volume groups capturing/having captured the physical paths in a file which can be editted to your taste between the export and the import step. See the man pages for more information.

Regards!

...JRF...

[generic_1]

Interesting, vgimport -s wasnt run ans we are very careful about the import stuff. I am wondering though if the lvmtab is rewrote with when say you added a new volume group and some of the old ones were failed over to the B path. Is lvm smart enough to to keep things where they are supposed to be on the primary path, and/or is this a bug?