Hi!

Background:
After a power outage, our two FastTs were in a really bad state,
lots of mappings missing etc. It took IBM support and manufacturer
support to come back to a sane state.

Now that I thought everything is fine again, I noticed on one of
our boxes:

AIX100P002:NOSW:/root#lsvg
rootvg
fastt01

So far so good.

AIX100P002:NOSW:/root#lsvg -p fastt01
fastt01:
PV_NAME PV STATE TOTAL PPs FREE PPs FREE DISTRIBUTION
hdisk3 active 2079 146 00..00..00..00..146

So far so good. But:

AIX100P002:NOSW:/root#lspv
hdisk0 00cdfb0d63331e31 rootvg active
hdisk1 00cdfb0d63331f12 rootvg active
hdisk3 00cdfb0d14c3cb1b fastt01 active
hdisk2 00cdfb0d14c3cb1b fastt01 active

Oops. hdisk2 claims to be active in vg fastt01 as well, having the
same PVID as hdisk3.

Is it safe to try reducevg or rmdev on hdisk2? I am not sure, I don't
want to lose hdisk3 with the same PVID.

Just some other random info:
AIX100P002:NOSW:/root#lsvg fastt01
VOLUME GROUP: fastt01 VG IDENTIFIER: 0053418a00004c00000000ff688768ed
VG STATE: active PP SIZE: 64 megabyte(s)
VG PERMISSION: read/write TOTAL PPs: 2079 (133056 megabytes)
MAX LVs: 256 FREE PPs: 146 (9344 megabytes)
LVs: 4 USED PPs: 1933 (123712 megabytes)
OPEN LVs: 4 QUORUM: 2
TOTAL PVs: 1 VG DESCRIPTORS: 2
STALE PVs: 0 STALE PPs: 0
ACTIVE PVs: 1 AUTO ON: yes
MAX PPs per VG: 32512 0
MAX PPs per PV: 3048 MAX PVs: 10
LTG size: 128 kilobyte(s) AUTO SYNC: no
HOT SPARE: no BB POLICY: relocatable

I noticed a Quorum: 2 here, that doesn't seem to be sane.

AIX100P002:NOSW:/root#lspv -l hdisk2
hdisk2:
LV NAME LPs PPs DISTRIBUTION MOUNT POINT
loglv01 1 1 01..00..00..00..00 N/A
prfsw 12 12 12..00..00..00..00 /prf/staffware
oraclepgm 160 160 160..00..00..00..00 /app/local/oracle
prf_oradta 1760 1760 416..416..415..416..97 /prf/oracle
AIX100P002:NOSW:/root#lspv -l hdisk3
hdisk3:
LV NAME LPs PPs DISTRIBUTION MOUNT POINT
loglv01 1 1 01..00..00..00..00 N/A
prfsw 12 12 12..00..00..00..00 /prf/staffware
oraclepgm 160 160 160..00..00..00..00 /app/local/oracle
prf_oradta 1760 1760 416..416..415..416..97 /prf/oracle

Any hint how I should handle this situation?


Have a nice day,

Kai.

In a simple SAN environment with 2 FC HBA to the same SAN Storage you
get this kind of problem pretty easy as long as you do not use any
Zoning or load balancing software

In this kind of setup the output from lspv would be absolut correct
because the LVM does see the same Disk through two different adapters.
So from a working point of view you should have no problems because the
LVM takes the first disk it sees and uses this one.

But for further help we need a little more details about the HW SAN
setup
Also you are talking about 2 FASTT's and about this SAN-Storage i do
not know to much.

At least DO NOT do any reducevg or rmdev

hth
Hajo

The best course of actions is to unmount all filesystems in fastt01,
then varyoffvg, then exportvg. Verify that all hdisks in fasst01 gone,
then redefine vg back with importvg. These steps should take care of
duplication of pvid in ODM.

Sergey

Forget to mention - make sure you also run rmdev -dl again unneeded
hdisk device before importvg.

Hi!


* Hajo Ehlers <service@metamodul.com>:
> In this kind of setup the output from lspv would be absolut correct
> because the LVM does see the same Disk through two different adapters.

Ah, sure, you are right.
iostat -a tells me hdisk3 is on fcs0, and hdisk2 is on fsc1.

> So from a working point of view you should have no problems because the
> LVM takes the first disk it sees and uses this one.

I see from iostat, that only hdisk2 on fcs1 gets all the data. Somehow
strange again, when the vg claims to consist of hdisk3.

> At least DO NOT do any reducevg or rmdev

I won't. I won't even touch that for a while at all. There is too much
other stuff going on other machines, that I need to take care of,
involving VIO Servers that I don't know anything about.

Well, thanks for your hints.

-Kai.

Hi

sergeyt.17@gmail.com wrote:
> The best course of actions is to unmount all filesystems in fastt01,
> then varyoffvg, then exportvg. Verify that all hdisks in fasst01 gone,
> then redefine vg back with importvg. These steps should take care of
> duplication of pvid in ODM.

It would not because the same disk will be seen by the LVM through two
pathes.

Hajo