Logical volume name conflict in two volume group

dantares · December 5, 2009, 3:39am

Hello,

I am a french computer technician, and i speak English just a little.

On Aix 5.3, I encounter a name conflict logical volume on two volume group.

The first volume lvnode01 is OK in rootvg and mounted. It is also consistent in the ODM

root # lsvg -l rootvg |grep lvnode01 
lvnode01           jfs2       32    64    2    open/syncd    /users/node01 

root # lslv lvnode01 
LOGICAL VOLUME:     lvnode01              VOLUME GROUP:   rootvg 
LV IDENTIFIER:      00c7beec00004c00000001249820e29f.19 PERMISSION:  read/write 
VG STATE:           active/complete        LV STATE:       opened/syncd 
TYPE:               jfs2                   WRITE VERIFY:   off 
MAX LPs:            512                    PP SIZE:        32 megabyte(s) 
COPIES:             2                      SCHED POLICY:   parallel 
LPs:                32                     PPs:            64 
STALE PPs:          0                      BB POLICY:      relocatable 
INTER-POLICY:       minimum                RELOCATABLE:    yes 
INTRA-POLICY:       middle                 UPPER BOUND:    32 
MOUNT POINT:        /users/ node01        LABEL:          /home/ node01 
MIRROR WRITE CONSISTENCY: on/ACTIVE 
EACH LP COPY ON A SEPARATE PV ?: yes 
Serialize IO ?:     NO 

root # odmget -q name= lvnode01 CuAt 

CuAt: 
        name = " lvnode01" 
        attribute = "lvserial_id" 
        value = "00c7beec00004c00000001249820e29f.19" 
        type = "R" 
        generic = "D" 
        rep = "n" 
        nls_index = 648 

Command getlvcb is consistent 

root # getlvcb -AT lvnode01 
         AIX LVCB 
         intrapolicy = m 
         copies = 2 
         interpolicy = m 
         lvid = 00c7beec00004c00000001049820e29f.19 
         lvname = lvnode01 
         label = /home/ node01 
         machine id = 7BEEC4C00 
         number lps = 32 
         relocatable = y 
         strict = y 
         stripe width = 0 
         stripe size in exponent = 0 
         type = jfs2 
         upperbound = 32 
         fs = vfs=jfs2:log=/dev/alt_hd8:mount=true:quota=no:account=false 
         time created  = Tue Oct 27 23:33:44 2009 
         time modified = Wed Oct 28 02:55:59 2009

Another logical volume with the same name lvnode01 is present in another volume group (datavg), but in the closed state.

root # lsvg -l datavg | grep lvnode01 
lvnode01           jfs2       64    64    31   closed/syncd  /users/node01

I want to delete the logical volume lvnode01 in the second volume group datavg without impacting the first logical volume lvnode01 in rootvg. The server is critical.

With the lqueryvg command I could read the lvid in the volume group datavg on one of physical volume (hdisk10).

it is the lvid 00c7beec00004c0000000104e69b04cf.7 for the logical volume lvnode01

Lsvg �p datavg |grep hdisk10 
Hdisk10         active            1736        3           00..00..00..00..03 

root # lqueryvg -p hdisk10 -At 
Max LVs:        512 
PP Size:        24 
Free PPs:       64 
LV count:       7 
PV count:       31 
Total VGDAs:    31 
Conc Allowed:   0 
MAX PPs per PV  2032 
MAX PVs:        64 
Quorum Setting  1 
Auto Varyon ?:  1 
Conc Autovaryo  0 
Varied on Conc  0 
Logical:        00c7beec00004c0000000104e69b04cf.1   logva01 1 
                00c7beec00004c0000000104e69b04cf.2   logsa01 1 
                00c7beec00004c0000000104e69b04cf.3   data02 1 
                00c7beec00004c0000000104e69b04cf.4   tm01lv 1 
                00c7beec00004c0000000104e69b04cf.5   pu01lv 1 
                00c7beec00004c0000000104e69b04cf.6   data01lv 1 
                00c7beec00004c0000000104e69b04cf.7   lvnode01 1 
Physical:       00c7beece64601ba                1   0 
                00c7beece6460796                1   0 
                00c7beece6460c05                1   0 
                00c7beece64610ad                1   0 
                00c7beece6461618                1   0 
                00c7beece6461b37                1   0 
                00c7beece64620c9                1   0 
                00c7beece64625e9                1   0 
                00c7beece6462b79                1   0 
                00c7beece6463220                1   0 
                00c7beece64637dc                1   0 
                00c7beece6463fa2                1   0 
                00c7beece6464799                1   0 
                00c7beece64650b9                1   0 
                00c7beece6465775                1   0 
                00c7beece6465ea6                1   0 
                00c7beece646653b                1   0 
                00c7beece6466c7a                1   0 
                00c7beece64673ee                1   0 
                00c7beece6467b4d                1   0 
                00c7beece646825e                1   0 
                00c7beece6468aaf                1   0 
                00c7beece64692d9                1   0 
                00c7beece6469b38                1   0 
                00c7beece646a399                1   0 
                00c7beece646ac4c                1   0 
                00c7beece646b596                1   0 
                00c7beece646bfc1                1   0 
                00c7beece646ca29                1   0 
                00c7beece646d46d                1   0 
                00c7beece646ddc0                1   0 
Total PPs:      53816 
LTG size:       128 
HOT SPARE:      0 
AUTO SYNC:      0 
VG PERMISSION:  0 
SNAPSHOT VG:    0 
IS_PRIMARY VG:  0 
PSNFSTPP:       16128 
VARYON MODE:    0 
VG Type:        1 
Max PPs:        130048

I tried with the commands lchangelv and ldeletelv to delete or rename the second logical volume from its lvid but this does not work.

root # lchangelv -l 00c7beec00004c0000000104e69b04cf.7 -n lvnode01bad 
0516-082 lchangelv: Unable to access a special device file. 
         Execute redefinevg and synclvodm to build correct environment. 

root # ldeletelv -l 00c7beec00004c0000000104e69b04cf.7 
0516-046 ldeletelv: Cannot delete logical volume before partitions removed.

What is the solution to remove this second logical volume the same without impacting the availability of server?

Is that the synclvodm command could solve the problem?

Thanks a lot for your answer.

---------- Post updated 12-05-09 at 12:38 AM ---------- Previous update was 12-04-09 at 10:53 PM ----------

Hello,

After some research I think the command synclvodm could solve the problem of name conflict by renaming the logical volume automatically by default.

Have you ever used this command in this situation?

---------- Post updated at 12:39 AM ---------- Previous update was at 12:38 AM ----------

After some research I think the command synclvodm could solve the problem of name conflict by renaming the logical volume automatically by default.

Have you ever used this command in this situation?

wwwzviadi · December 5, 2009, 5:08am

Did you try to first umount the fs located on the LV? and then try

 smit rmlv

and indicate your LV ..

dantares · December 5, 2009, 5:45am

I can't unmount the file system because it is already used in another volume group rootvg.

For this reason i can't remove the logical volume with name lvnode01.

In odm, the logical volume lvnode01 exists once and is present only in the volume group rootvg.

In fact, I try to delete the duplicate of this lvnode01 logical volume in volume group datavg

wwwzviadi · December 5, 2009, 6:22am

so as we see thereis mirroring .. so try this

 smit rmlvcopy

and indicate PV from which you want to remove LV

dantares · December 5, 2009, 9:04am

both copies reported by the command lslv are on the physical volume of rootvg: hdisk0 and hdisk1.

Both copies will not affect the datavg vg.

In fact I try to delete, without impacting applications, the problem of name conflict logical volume on this server. There are two times the logical volume lvnode01 : once in the volume group rootvg (mounted and active) and a second time in another volume group datavg (unmounted, not in the ODM but present in VGDA off physical volume related volume group datavg).

After some research I think the command synclvodm could solve the problem of name conflict by renaming the logical volume automatically by default.

bakunin · December 5, 2009, 9:36am

Unfortunately i don't think so. "synclvodm" updates the contents of the ODM with the data of the VGDA (volume group descriptor area) and the LVCB (logical volume control block), nothing more, nothing less. You have this name conflict in the physical configuration (your VG/LV information as it is stored on disk) and your problem is not that the ODM contains other data than your disks. Therefore "synclvodm" will most likely not help you at all.

I'd try the following, which needs some downtime, but should be save. CAUTION: I cannot recreate your problem condition on the fly so the following is UNTESTED:

use "varyoffvg" to completely unmount both of the VGs containing the conflicting LV.
Use "exportvg" to get both VGs completely out of the system configuration.
then use "synclvodm" to get a clean system configuration in the ODM
"importvg" and "varyonvg" one of the VGs and delete the offending LV (you said you want to delete one of them anyways, but of course you could recreate and copy it under a different name to remove the conflict)
"importvg" the other VG

The name conflict should be removed.

I hope this helps.

bakunin

dantares · December 5, 2009, 10:57am

I wanted to use the command synclvodm to rename the logical volume lvnode01 in default in the volume group datavg.

So I could remove the default logical volume in volume group datavg without stopping applications. In fact I am forced to stop applications when using a importvg / exportvg.

bakunin · December 5, 2009, 1:53pm

To be honest i think there is no way around that - at least no safe way. It is better to let the customers swallow this bitter pill than to risk data loss and unexpected interruption of service.

In the first case they might be rather less overjoyed, in the latter they might be pretty infuriated.

If your customers still object: explain to them that not going down for service downtime will bear the risks of data loss, unexpected outage and perhaps a long downtime for data recovery, then let them decide if they are willing to take it - this usually works wonders in term of achieving their cooperation.

I hope this helps.

bakunin

wwwzviadi · December 5, 2009, 2:18pm

So is you problem solved?

dantares · December 6, 2009, 3:23am

I'll do tomorrow and I would inform you of the result

Thank you for your answers

dantares · December 7, 2009, 12:12pm

Finally, I only used the command synclvodm.

It worked:

root # synclvodm -v datavg
synclvodm: Logical volume logva01 updated
synclvodm: Logical volume logsa01 updated
synclvodm: Logical volume data02 updated
synclvodm: Logical volume tm01lv updated
synclvodm: Logical volume pu01lv updated
synclvodm: Logical volume data01lv updated
0516-530 synclvodm: lvnode01 Logical volume name changed to fslv00
synclvodm: Logical volume fslv00 updated

Subsequently, I have deleted the logical volume

Thank you for your advice.