Originally posted by: grukrz1

Hello,

I have two node HACMP 5.4.0.1 installed. The cluster
is built of two resource groups (RG1 and RG2) each one
have configured its application server (accordingly
AS1 and AS2) and one service address per each RG.

RG1 has AS1 - home node NODE1
RG2 has AS2 - home node NODE2

There is one shared VG in the cluster - the VG is
configured in RG1. The VG is NOT CONC CAPABLE - SHOULD
BE ACTIVE ONLY ON ONE NODE AT THE TIME = ON THE NODE WHERE RG1 IS ONLINE)

RG1 is a parent of RG2 (because RG1 has the shared VG and
has to be stared before RG2).

Verification/synchronization passes OK. No errors.

Cluster starts properly. After the startup both RGs are brought up properly on their home nodes.

1. clfindres

---

Group Name State Node

---

RG1 ONLINE NODE1
OFFLINE NODE2

RG2 ONLINE NODE2
OFFLINE NODE1

Resource groups policies are set as follows:
Resource Group Name
RG1
Participating Node Name(s)
NODE1 NODE2
Startup Policy
Online On Home Node Only
Fallover Policy
Fallover To Next Priority Node In The List
Fallback Policy
Fallback To Higher Priority Node In The List

Resource Group Name
RG2
Participating Node Name(s)
NODE2 NODE1
Startup Policy
Online On Home Node Only
Fallover Policy
Fallover To Next Priority Node In The List
Fallback Policy
Fallback To Higher Priority Node In The List

cldump - shows proper cluster status UP/STABLE, diskhb
networks are UP.
The problem is when I try to create from C-SPOC shared
LV or FS on shared VG. I do it from parent node -
where RG1 is online and shared VG is varied on.
The command I run was:

Command_to_Execute follows below:
>> main()
{
export _CSPOC_MODE=shared
/usr/sbin/cluster/cspoc/smitlvm -17 "$@"
}
main 'RG1' -y'test_lv' -t'jfs2' -c'2' datavg 8
(hacmp smit menu:
smitty cl_lv / Add a Shared Logical Volume / then
selected:

#Resource Group Volume
Group
RG1 datavg

, next selected Auto-Select:

Auto-select
NODE01 vpath0
NODE01 vpath2

...
I observed, that during shared LV creation via C-SPOC,
the shared VG is (???) being varied-on on NODE02 also = the VG is varied-on on both nodes at the time!!!
HACMP reports no errors - the status is STABLE/OK,
both resource groups are ONLINE as before!!! On parent RG1 node,
are still monted all shared filesystems but are not useable (database has no access to this filesystems!!) and the VG is not accessible although is see it on "lsvg -o" output.

1. lsvg -o

rootvg
datavg

1. lsvg -l datavg

0516-013 : The volume group cannot be varied on
because
there are no good copies of the descriptor
area.

Varyoffing the shared VG on NODE02 and varying-on it on NODE01 doesn't solve the problem - still "lsvg -l datavg" returns error as above.

To fix problem I need to stop cluster first on
NODE02, then on NODE01 and start again on NODE01 and
again on NODE02.
I guess this is C-SPOC bug in HACMP 5.4.0.1 or maybe C-SPOC can't be used for
LV/FC creation on running cluster and ONLINE VGs (??)

Maybe there is already fix for it?

Are here anybody using HACMP 5.4? Anyone met/observed
similiar C-SPOC problem as well?

In older HACMP versions, 4.4, 4.5, 5.1, 5.2, 5.3 I had never such problems creating shared LVs or filesystems in shared VG using C-SPOC.

Any ideas?

Thanks in advance for any!

Originally posted by: grukrz1

seems to be a bug...

described in APAR IY90392.

no fix yet avaiable.

http://www-1.ibm.com/support/docview.wss?uid=isg1IY90392

Originally posted by: SystemAdmin

Looks like this is a duplicate of APAR IY93866 and IY92701
"APAR is sysrouted TO one or more of the following:
IY92701 IY93866"

Look here: http://www-1.ibm.com/support/docview.wss?uid=isg1IY93866
and here: http://www-1.ibm.com/support/docview.wss?uid=isg1IY92701
Both of the above reports have a link to the fix...

Originally posted by: grukrz1

as I wrote, I met the problem in HACMP 5.4.

The links you pasted are related accordingly to HACMP 5.2 and HACMP 5.3.
The APAR link for HACMP 5.4 http://www-1.ibm.com/support/docview.wss?uid=isg1IY90392 doesn't have fix available.

Do you think that the fix which is available for HACMP 5.2 or HACMP 5.3 will work with HACMP 5.4??

thx.

Originally posted by: SystemAdmin

You're right.... :(

The APAR report does say that the fix has been made:
[i]Problem conclusion

Correct code added in 551404 to update timestamp to do so
without setting or leaving a reserve on the volume group.[/i]

Since the fixes have been posted for 5.2 and 5.3, and the report for 5.4 states the fix has been added then perhaps an email to support is in order. The modification dates for all three APARs are within 10 days of each other (1/21/07 and 1/31/07).

I would not apply the fix which is available for HACMP 5.2 or 5.3. You are likely to run into dependencies between that fix and other changes that were made in 5.2/5.3 that are not reflected 5.4. That is, if the system even allows you to apply the fix.

Originally posted by: SystemAdmin

I have had the same Problem. There is an IFIX available. You can get it fron the IBM Support.........

Originally posted by: SystemAdmin

Hi!
We have the same HACMP version 5.4.01 and have similar problems.
We have tried to remove second copy of LV and add pv to VG by C-SPOC and we get:

10/30/07 23:10:39 ========== C_SPOC COMMAND LINE ==========
10/30/07 23:10:39 /usr/es/sbin/cluster/sbin/cl_extendvg -cspoc -g
oracle_prod -Rnode1 oracle_prod hdiskpower33
10/30/07 23:10:40 node1: success: clresactive -v oracle_prod
10/30/07 23:10:40 node2: success: clresactive -v oracle_prod
10/30/07 23:10:40 node1: success: lspv
10/30/07 23:10:41 node1: success: cllvmcmd -extendvg -f oracle_prod
hdiskpower33
10/30/07 23:10:41 node1: success: varyonvg -n -b -u oracle_prod
10/30/07 23:10:56 node2: success: eval clupdatevg oracle_prod
00c4bf6f0dfef704
10/30/07 23:10:57 cl_extendvg: Error re-locking volume group oracle_prod
10/30/07 23:10:57 ': success: varyonvg -n oracle_prod
10/30/07 23:10:57 node1: FAILED: varyonvg -n oracle_prod
10/30/07 23:10:57 node1: 0516-013 varyonvg: The volume group cannot be
varied on because
10/30/07 23:10:57 node1: there are no good copies of the descriptor
area.
10/30/07 23:10:57 node1: RETURN_CODE=20
10/30/07 23:10:57 20: success: varyonvg -n oracle_prod
10/30/07 23:10:57 1>&2: success: varyonvg -n oracle_prod
10/30/07 23:10:57 '%1$s: success: varyonvg -n oracle_prod
10/30/07 23:10:57 node1: FAILED: varyonvg -n oracle_prod
10/30/07 23:10:57 node1: 0516-013 varyonvg: The volume group cannot be
varied on because
10/30/07 23:10:57 node1: there are no good copies of the descriptor
area.
10/30/07 23:10:57 node1: RETURN_CODE=20
10/30/07 21:54:09 ========== C_SPOC COMMAND LINE ==========
10/30/07 21:54:09 /usr/es/sbin/cluster/sbin/cl_rmlvcopy -cspoc -g
oracle_prod -Rnode1 prdvbank_data_3 1 hdiskpower
32
10/30/07 21:54:09 node1: success: clresactive -v oracle_prod
10/30/07 21:54:09 node2: success: clresactive -v oracle_prod
10/30/07 21:54:10 node1: success: lspv
10/30/07 21:54:12 node1: success: cllvmcmd -rmlvcopy oracle_prod
prdvbank_data_3 1 hdiskpower32
10/30/07 21:54:13 node1: success: varyonvg -n -b -u oracle_prod
10/30/07 21:54:27 node2: success: eval clupdatevg oracle_prod
00c4bf6f038ac2f0
10/30/07 21:54:27 cl_rmlvcopy: Error re-locking volume group oracle_prod
10/30/07 21:54:27 ': success: varyonvg -n oracle_prod
10/30/07 21:54:27 node1: FAILED: varyonvg -n oracle_prod
10/30/07 21:54:27 node1: 0516-013 varyonvg: The volume group cannot be
varied on because
10/30/07 21:54:27 node1: there are no good copies of the descriptor
area.
10/30/07 21:54:27 node1: RETURN_CODE=20
10/30/07 21:54:27 20: success: varyonvg -n oracle_prod
10/30/07 21:54:27 1>&2: success: varyonvg -n oracle_prod
10/30/07 21:54:27 '%1$s: success: varyonvg -n oracle_prod
10/30/07 21:54:27 node1: FAILED: varyonvg -n oracle_prod
10/30/07 21:54:27 node1: 0516-013 varyonvg: The volume group cannot be
varied on because
10/30/07 21:54:27 node1: there are no good copies of the descriptor
area.
10/30/07 21:54:27 node1: RETURN_CODE=20

All filesystems on oracle_prod are inaccessible.
lsvg -o shows that vg is active.

We are going to install HACMP 5.4 Service Pack 2 but I wonder if that helps us? Have You resolved Your problems?