missing filesystems from /etc/lvmtab

[Jeff Disney]

I was performing a data migration at work and I had to vgexport some volume groups from one cluster node to another, when I perfomed a vgimport on the other node it did not write the entries to the /etc/lvmtab file, I did this for six seperate volume groups and two of them imported correctly and the other four were not written to the file, causing them to fail when I attempted to start the cluster package. Any ideas on what would cause this?

[Steven E. Protter]

Baed on the information provided thus far, I would suspect the Romulans...

Were there any errors on the vgexport of note? On the vgimport?

If not check the control console for your disk cluster and see if ownerhip on the virtual disk/volume groups(whatever the designation) has been toggled to the new server and world wide name.

SEP

[A. Clay Stephenson]

One possible cause of this problem is non-unique minor device numbers on the group device node. By convention, vg02 uses 64 0x020000, vg03 uses 64 0x030000 but that is simply convention. Make absolutely certain that the minir device number you choose is unique to that system. Often when importing, you will choose the same minor device number as on another system HOWEVER that puppy may already be in use. In that case, chaos is almost ensured.

[Saurav_1]

Hi,

Try this on node 1
# ll /etc/vg*/group

Try the same in node 2

The minor number in the output of both the listings should be similar and check for reuse of numbers in the output of second server for the Volume groups. This should be avoided.

[David Ritchie]

1. Make certain that you recreate the /dev/vf*/group file with an unique minor
number... coordinate this among the various machines in the cluster.

2. Make certain you are not using the -p option accidently on the vgimport. If you do
this, it looks like you are changing things when you are not.

3. Performing 'strings /etc/lvmtab' into a file before and after vgimport/vgexport will allow you to see exactly what changed by diffing the two output files.

4. Make certain that you are using the -s options when attempting to import a shared volume group to a SG node that does not have that volume group actived currently.

5. Perform a strings on /etc/lvmtab and make certain that the vg names on the imported volumes are not present. Likewise, make certain that the physical names of the disks in question are not present To my knowledge,
trying to reimport the same physical volume to another volume group

6. You may need to use
ioscan -f
insf -e
to get the devices presented to the machine
properly.

7. Make certain all the volume groups in question are included in the MC/ServiceGuard package control file....

Just some ideas off the top of my head. Exact errors that you are seeing would help narrow this down more quickly.

-- Dave

[Jeff Disney]

The reason the vg information did not get written to file is because the root filesystem was at 100% at the time I attempted the import, the majority of data is on a SAN, after the root filestystem was reduced I was able to import correctly.

Thanks for everyones help.