Hi all,
I have a running HACMP cluster that uses Enanced Concurrent VG (AIX
5.3ML2 HACMP5.2)
I'm planning a soft migration from powerpath disk to vpath disk using
mirror feature.

As one of the first step, form the node that have the vg active, I
try:

#extendvg dymmyvg vpath0
The distribution of this command (111) failed on one or more passive
nodes.
0516-792 extendvg: Unable to extend volume group.

Has anyone successfully extended a vg enanced-concurrent varyed-on
(without the vary-off command execution)?

Many Thank's in advance

Hi,

- I assume you user first cfgmgr -S
- Use extendvg4vp for vpaths !
- Create an PVID first on the disk to add
- Create the same PVID on the other node using the concurrent cluster

Use on both nodes: chdev -l vpath1 -a pv=yes (vpath1, 2, 3 etc. off
course)

mirror/unmirror should go well.

> - I assume you user first cfgmgr -S
done

> - Use extendvg4vp for vpaths !
the same error of extendvg.

> - Create an PVID first on the disk to add
> - Create the same PVID on the other node using the concurrent cluster
>
> Use on both nodes: chdev -l vpath1 -a pv=yes (vpath1, 2, 3 etc. off
> course)
>
done soon after cfgmgr

may I need of same AIX fix?

If you haven't: Try the extendvg from the other node !. Sometimes it
will work.
Otherwise: If you use Oracle and it is possble stop/start Oracle will
release some ' locking'

Fix was needed for AIX 5.2 below ML 6. Not for 5.3 as far as I know.

GoodLuck
pvb265 wrote:
> > - I assume you user first cfgmgr -S
> done
>
> > - Use extendvg4vp for vpaths !
> the same error of extendvg.
>
> > - Create an PVID first on the disk to add
> > - Create the same PVID on the other node using the concurrent cluster
> >
> > Use on both nodes: chdev -l vpath1 -a pv=yes (vpath1, 2, 3 etc. off
> > course)
> >
> done soon after cfgmgr
>
> may I need of same AIX fix?

Bobohoolie wrote:
> If you haven't: Try the extendvg from the other node !. Sometimes it
> will work.
> Otherwise: If you use Oracle and it is possble stop/start Oracle will
> release some ' locking'
>
> Fix was needed for AIX 5.2 below ML 6. Not for 5.3 as far as I know.
>
> GoodLuck
> pvb265 wrote:
>
>>>- I assume you user first cfgmgr -S
>>
>>done
>>
>>
>>>- Use extendvg4vp for vpaths !
>>
>>the same error of extendvg.
>>
>>
>>>- Create an PVID first on the disk to add
>>>- Create the same PVID on the other node using the concurrent cluster
>>>
>>>Use on both nodes: chdev -l vpath1 -a pv=yes (vpath1, 2, 3 etc. off
>>>course)
>>>
>>
>>done soon after cfgmgr
>>
>>may I need of same AIX fix?
>
>
Do an lquerypr -vh /dev/vpathx and see if there is a persistent reserve.
If there is, do an lquerypr -ch /dev/vpathx and then run cfgmgr
again and the PVID and vg assignment should come up. If you have added
the disk to a vg on one system, I would not do an extendvg again from
another server as you risk corrupting the VGDA on the drive.

Phil,

Don't agree.

If you have it on one system in the CONCURRENT VG, you have a
semi-corrupted situation. If the extendvg fails and the disk is only
av. on 1 side you have a prob. already. YOu should remove it from the
vg (reducvg off course) and then try it again from the other node (that
is what I meant with trying it again !) to avoid the 111111 sit.

Marcel

Phil Langerholc wrote:
> Bobohoolie wrote:
> > If you haven't: Try the extendvg from the other node !. Sometimes it
> > will work.
> > Otherwise: If you use Oracle and it is possble stop/start Oracle will
> > release some ' locking'
> >
> > Fix was needed for AIX 5.2 below ML 6. Not for 5.3 as far as I know.
> >
> > GoodLuck
> > pvb265 wrote:
> >
> >>>- I assume you user first cfgmgr -S
> >>
> >>done
> >>
> >>
> >>>- Use extendvg4vp for vpaths !
> >>
> >>the same error of extendvg.
> >>
> >>
> >>>- Create an PVID first on the disk to add
> >>>- Create the same PVID on the other node using the concurrent cluster
> >>>
> >>>Use on both nodes: chdev -l vpath1 -a pv=yes (vpath1, 2, 3 etc. off
> >>>course)
> >>>
> >>
> >>done soon after cfgmgr
> >>
> >>may I need of same AIX fix?
> >
> >
> Do an lquerypr -vh /dev/vpathx and see if there is a persistent reserve.
> If there is, do an lquerypr -ch /dev/vpathx and then run cfgmgr
> again and the PVID and vg assignment should come up. If you have added
> the disk to a vg on one system, I would not do an extendvg again from
> another server as you risk corrupting the VGDA on the drive.

The exact procedure I followed is:

cfgmgr -l fcsx
for "each disk 2107" for "each node of the cluster"
chdev -l disk -reserve_policy=no_reserve -P
chdev -l disk -pv=yes -P
done
cfallvpath
extendvg (or extendvg4vp) dummyvg vpathx

:-(((

only for completion...
I have opened a PMR and I was suggested to installing
IY77507 IY78533 and IY66001

unfortunately I can't update the system
so I gonna try to enlarge the vg with the resource group in inactive
state.

I'll update the thread with command sequence and relative return code

I'm awating the results with some curiosity....

Marcel
pvb265 wrote:
> only for completion...
> I have opened a PMR and I was suggested to installing
> IY77507 IY78533 and IY66001
>
> unfortunately I can't update the system
> so I gonna try to enlarge the vg with the resource group in inactive
> state.
>
> I'll update the thread with command sequence and relative return code

The PMR action plan suggests:

- stop of the resource group
- varyoffvg dummyvg
- varyonvg -nc dummyvg
- extendvg4vp dummyvg vpath0
- start of the resource group

as a backup action

- restart of the cluster
- extendvg4vp dummyvg vpath0
- start of the resource group

After a spech with the Country IBM referent we modify the action plan
in:

- stop of the cluster
- varyoffvg dummyvg
- varyonvg dummyvg
dummyvg should remain Enhanced Concurrent Capable, but I mount
it in normal mode to do the extentions
- extendvg4vp dummyvg vpath0
- importvg -L dummyvg disk on the other node of the cluster
- varyoffvg dummyvg
- cluster verification & syncro
- start of the cluster

Anyway before applying the modified action plan I try to follow the
original one, but with unpredictable return codes. With some vpaths
works, with someothers halfworks (update the VGDA, but not the odm),
with others return the original error.

In my opinion there is an high probability that the cause is in
gsclvmd...

So, a bit disappointed, I applied the modified plan.
All works and the extendvg4vp enlarged the dummyvg...
My machines are too downlevel and very full of lacks :-(

After that my curiosity pulls me to try the next step:

mirrorvg -s -c 2 dummyvg vpath0 vpath1
0516-1509 : VGDA corruption: physical partition info for this LV
is invalid.
0516-842 : Unable to make logical partition copies for logical
volume.
0516-1199 mirrorvg: Failed to create logical partition copies for
logical volume dummylv.
0516-1200 mirrorvg: Failed to mirror the volume group

Now, IBM support is working for analyze this new issue......

Regards.