Error- new LV created; VG-Reimport not followed

[S.N.S]

Hi Again!

Well, this is just a confirmation question:

Environment: OS - 11.23 ; IA 64;2 Nodes clustered with HP SG 11.18

We had to move to data from a LV on the server to a new LV in the SAN.

The initial lvol3 on the SAN was mounted /export .


What was done (on the same VG):
1. lvol3 was removed
2. New LV created & name lvol3 itself

I had made the new mount point copying data to the new location at /appl on the SAN.
3. Also, I later made changes to the pkg control scripts for the related lines for lvol3

But, the VG-ReImport procedure wasnt followed ...and my my - did I err...

So now on the Primary node, I get the error:
vxfs fsck: /dev/vgora_data/rlvol3:cannot stat /dev/vgora_data
ERROR: Function check_and_mount
ERROR: Failed to fsck one of the logical volumes

And when I tried the VG-Reimport, on the secondary node I get :
Beginning the import process on Volume Group "vgora_data".
Couldn't access the list of physical volumes for volume group "/dev/vgora_data".

The solution I see is to re-do the whole procedure of recreating the lvol3 after halting the pkg. And then do the Re-import
Questions: 1 . Am I mistaken (with the above solution)?
2. Also, any extra precautions at all need to be taken during exclusive activation?

The Cluster is running, pkg is down - I had to exclusively activate the shared VG and manual mount them to keep Oracle running - yeah, I should have been more careful.
Please let me know your valuable suggestions...
Dunke/Merci
SNS

[Steven E. Protter]

Shalom,

After you clone a mounted logical volume fsck needs to be run prior to mounting the logical volume.

Try fsck before you bother doing the import again.

SEP

[S.N.S]

Peace to you too SEP,

Obviously
fsck -F vxfs /dev/vgora_data/rlvol3
was done giving the error

""vxfs fsck: cannot stat /dev/vgora_data/rlvol3"
What needs to be done?

Dunke,
SNS

[S.N.S]

Here is the package log...

Am I overlooking something real simple?

Dunke/Merci

[Benoy Daniel]

Can you manually activate the VG and mount the file system and see if it is working.

[S.N.S]

The VG can be activated - as the logs show- I was able to mount the lvol3 also - but when the Cluster is started, I get the error as previously attach logs show.

Thank you!

[Benoy Daniel]

In this case there is nothing wrong with the VG/LV. please verify the package control file once again.There may be some syntax error or extra character added into the file.

[RC Park]

Hi SNS -

I would try the following:

ON NODE 1:
1. Halt the package that turns on the VG that contains the LV in question.
2. remove the LV from the VG altogether
3. make sure there's no reference to this VG and associated mounts in /etc/fstab
4. make sure all other mount points are working by unmounting all, deactivating the VG, reactivating the VG and mounting again (manually)
5. create a mapfile of the vg and copy it over to node 2.
6. unmount filesystems and deactivate the vg

ON NODE 2:
7. export the vg and make sure all ref's to it are removed from the system
8. create the structures in /dev for the vg and run an import based on the copied mapfile
9. activate the vg and mount the filesystems

If this is working, then you've clear up any possible problems with the volume group and existing filesystems. If not, see if you can resolve any issues, otherwise, post the results here and we'll examine and respond.

Once working, you can deactivate on 2, go back to node 1, and then:

10. review the package files and make sure they are clean and setup properly and do NOT refer to the new LV. Test starting/stopping the patckage on both nodes. If this fails, seek to resolve issues and/or bring them here to the forum for further review.

AFTER you've proven things are working without the new LV, the do the following:

1. halt the package and re activate/mount manually on node 1
2. add the LV to the vg and mount the filesystem
3. repeat steps 5-9 and make sure you manually can activate and mount on both nodes

At this point, modify the package file on node 1, make sure it works to start the package and mount - then copy the package file to node 2, stop the package and activate on node 2 and you should be good to go.

RCP



3. Verify that the package files contain no references to this LV/filesystem and restart

[RC Park]

sorry, noticed extra text after my inits - please ignore :)

[S.N.S]

Thank You RC for the elaborate neat steps - appreciate it - even wanted to give 8/9 pts..However, the steps wasn't specific to the question in hand.

This is how I went about

1. Primary Node:

"vxfs fsck: /dev/vgora_data/rlvol3:cannot stat /dev/vgora_data" --
The pkg control script does fsck with the large files option (-o largefiles -see attached portion from the script)

However, I had run the made the newfs without the -o largefiles option.
Hence, naturally, ERROR: Failed to fsck one of the logical volumes

So you can either remove the largefile option from the script - which I did; or I guess you can newfs with the large files option

2. Secondary Node (2)

Strangely, the command the -s option didnt list out the PVs..
vgimport -v -s -m /tmp/vgoradata.map vgora_data

Hence the error "Couldn't access the list of physical volumes"

I check the map file - it showed all the VGID and all the lvols - I guess the PVs should have been there too?

So, without the -s option, I gave the list of PVs after the VG vgora_data, and it worked like a gem! :-)

Issue resolved!!

Thank all for your help,

Peace to all - may be some one can answer my last question regarding the map file
(Points , ofcourse!)

Merci
SNS

[RC Park]

SNS:

I'll try :) on answering your last question:

According to the man page for vgimport, you read the following:

Import the volume group /dev/vg01 that is located on physical disks

/dev/dsk/c0t1d0 and /dev/dsk/c0t3d0:

vgimport -v /dev/vg01 /dev/dsk/c0t1d0 /dev/dsk/c0t3d0

(the above 2 line(s) should be one if in fact it doesn't display as one...)

if you are sharing the same luns between systems, as you should be in serviceguard, you have them presented to both hosts. When you run vgimport as shown above, you can, and in your case possibly must specify the PVs on the command line.

The idea of vg export/import is that the LVM information is reatained on the disks, but removed temporarily from the system, and when vgimported it relies on the presence of the information on the disks to fully reestablish the VG.

Hope that helps...

RCP