vg disk device files changed

[Sam Lalonde]

I have a server with 5 volumes groups that are using XP-connected disks. According to the conf files in /etc/lvmconf, they were configured with the following disks:

vgx0
c0t0d3
c1t2d6
vgx1
c0t0d4
c0t8d4
c1t5d0
c4t5d0
c1t5d1
c4t5d1
vgx2
c0t3d4
c1t2d5
vx03
c1t2d7
vx04
c1t3d5
c4t3d5

The server suffered a failure of a fibre card and now a new fibre card has been inserted, and into another slot. Now the above device files no longer exist.

If I do a vgscan -p, I get the following:

vgx0
c10t0d3
c12t2d6
c11t8d3
c14t2d6
vgx1
c10t0d4
c10t8d4
c12t5d0
c12t5d1
c11t0d4
c11t8d4
c15t5d0
c14t5d1

unable to match

c10t0d5
c10t8d5
c11t0d5
c11t8d5

vgx2
c10t3d4
c12t2d5
c11t3d6
c14t2d5

unable to match

c10t11d5
c11t3d5

vx03
c12t2d7
c14t2d7
vx04
c12t3d5
c14t3d5

As you can see, for several of the volume groups, it is reporting more disks now than it had before.

Why would it be reporting more disks than what are in the .conf backup files?

How can I tell which new device files map to which original device files?

What would be the impact of issuing:

vgimport vgname pvpath

If the pvpath was a disk that was not originally in that volume group? (Could it do harm?)

What about the disks that say they belong to a volume group, but they cannot determine which?

Thanks for any information.

sam

[A. Clay Stephenson]

Well, the most straightforward approach would be to move the replacement card to the original slot.

You can also mv /etc/lvmtab /etc/lvmtab.orig and a vgscan -v to receate the lvmtab. This will ientify all the primary paths and then you can add the alternate paths later.

If you want to explicitly run vgimport with the pvpaths then you first need to do a vgexport of the VG, then recreate the /dev/vgxx directory, and then /dev/vgxx/group device node before running the vgimport. The vgexport will not alter data on the disks themselves only the /dev/vgxx/* entries and the entries in /etc/lvmtab.

[A. Clay Stephenson]

Well, the most straightforward approach would be to move the replacement card to the original slot.

You can also mv /etc/lvmtab /etc/lvmtab.orig and a vgscan -v to receate the lvmtab. This will identify all the primary paths and then you can add the alternate paths later.

If you want to explicitly run vgimport with the pvpaths then you first need to do a vgexport of the VG, then recreate the /dev/vgxx directory, and then /dev/vgxx/group device node before running the vgimport. The vgexport will not alter data on the disks themselves only the /dev/vgxx/* entries and the entries in /etc/lvmtab.

[Pete Randall]

Sam,

It looks like you now show alternate paths: vgx0 has gone from two to four disks and the names are fairly easy to match up; vgx1 has gone from six to twelve disks and requires a little more effort to match up; and so on.

Before you did your vgscan, did you rename /etc/lvmtab? I would rename /etc/lvmtab, then run vgscan -a without the -p option. If you don't like the results, you can always rename the old /etc/lvmtab back.


Pete

[Sam Lalonde]

I have never done a vgscan with -p yet, so my lvmtab is still ok.

Here is what I am thinking.

I backup the lvmtab then do a vgscan -a.

Hopefully this will get the volume groups to a point that I can activate them, maybe fsck the filesystems then mount them.

Then I have the task of dealing with those "extra" disks.

How could I go about matching the extra disks to their primary path?

Thanks for the help.

sam

[Sanjay_6]

Hi Sam,

Maybe this link would help.

http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000072570325

The itrc doc id is KBRC00012871.

Hope this helps.

Regds

[Sam Lalonde]

On my last post I meant "I have never done an vgscan WITHOUT a -p yet, so the lvmtab is still ok."

[Pete Randall · Accepted solution]

Sam,

If you didn't rename your /etc/lvmtab, that's probably why you're seeing all the extra disks: lvmtab has the old and vgscan is seeing the new.

Post your vgscan results after renaming.


Pete

[Sam Lalonde]

Once I moved my lvmtab file out of the road vgscan was able to create a new one for me that looked correct.

It still did complain about physical volumes that belong to a volume group, but it didn't know which.

However, I was able to activate all my volume groups, fsck the filesystems and mount them. I assume since vgchange allowed me to activate it, then it had the disks it required.

I also checked vgdisplay and every volume group is showing an alternate link for every disk.

Thanks everyone for your help.

sam