vgexport/vgimport problem

[Walter Goncalves]

Hi.

We have a M/C service guard cluster configuration. The package runs on one host and fails over to the other. However we ran SAM on the failover node and somehow used a disk whch was configured as part of the package to create a new (local)volume group.
We have since seen our error and exported the volume group on the failover node in order to free up that disk. However, when I try to run the vgimport command on the failover node to make that node aware of the shared volume group I get the following error. Logical Volume is not defined on any physical volume.
"/dev/vg_data/m_d1_01" is missing Physical Volumes.
Logical Volume is not defined on any physical volume.
"/dev/vg_data/m_d1_02" is missing Physical Volumes.
Logical Volume is not defined on any physical volume.
"/dev/vg_data/m_d1_03" is missing Physical Volumes.
Logical Volume is not defined on any physical volume.
"/dev/vg_data/m_d1_04" is missing Physical Volumes.

I know what I done wrong. I pvcreated a disk on the failover node that belonged to the cluster. Does anyone know how to reverse this. The only thing I can think of is to recreate the whole volume group structure - not something I want to do since this is a production server

[Bharat Katkar]

Hi,
I wonder if your production server is not in problem becuase when you use pvcreate from failover node it must have deleted the FileSystem on it (if you have used -f option) and if this FileSystem is part of any package that particular Package should fail.
Could you tell about "cmviewcl -v" output.

Regards,

[Borislav Perkov]

Hi,
You already have the answer.
You need to recreate the whole VG structure.
Before that make sure that you have backup.
Export the VG configuration on active node. Copy the file to Standby node. Make the phisical volumes and import the configuration to standby.

vgimport -m file_cfg_save vg_name /dev/dsk/cxtxd0 /dev/dsk/cxtxd1 .......

Rgeards,
Borislav

[Walter Goncalves]

Thanks for the replies.

The cluster is certainly working. Cmviewcl shows me the the package is up and running.
Also the database is still up.

Borislav. Does this mean that the volume group structure on the primary host also has to be recreated ?

[Borislav Perkov]

No, you should only export the VG, and copy it to standby for importing.

vgexport â m /tmp/vg_name.map â p â v vg_name
rcp /tmp/vg_name.map stand_by:/tmp/.

then on standby you should:

# vgexport vg_name -> delete the volume group
# mkdir /dev/vg_name
# mknod /dev/vgdb/group c 64 0x0n0000
# vgimport â m /tmp/vgdb.map vgdb \
> /dev/dsk/cxt0d0 /dev/dsk/cxt0d1 \
> /dev/dsk/cxt0d2 /dev/dsk/cxt0d3 \
> /dev/dsk/cxt0d4 /dev/dsk/cxt0d5 \
> .....

[Borislav Perkov]

Sorry

# vgimport -Â Â m /tmp/vg_name.map vg_name \
> /dev/dsk/cxt0d0 /dev/dsk/cxt0d1 \
> /dev/dsk/cxt0d2 /dev/dsk/cxt0d3 \
> /dev/dsk/cxt0d4 /dev/dsk/cxt0d5 \
> .....

Regards,
Bori

[Bharat Katkar]

Hi again,
If you say it's working and only the Failover node has lost the references then u could do as follows:
Assuming the VG is "vgxx"
1. On production do
# ls -la /dev/vgxx/group
Note down the minor no.
# vgexport -p -s -m vgxx.map vgxx
{ Please don't forget to give -p option }
# vgdisplay -v vgxx
Here note down all the PV's associated with that VG.

2. On Failover Node do
-- Copy the vgxx.map file from production server.(Use ftp or rcp)
# vgexport vgxx
This will remove the existing vgxx configuration on Failover node.
# mkdir /dev/vgxx
# mknod /dev/vgxx/group c 64
# vgimport -m vgxx.map vgxx ..
This PV1,PV2,.. are the one you noted above.

That's all. You have recreated you VG structure.

Hope that helps.
Regards,

[Bharat Katkar]

Does this mean that the volume group structure on the primary host also has to be recreated ?
Yes, you have to.
Regards,

[Rita C Workman · Accepted solution]

If you pvcreated this disk, then you destroyed the information on the disk that tells it what vgid it belongs to. To confirm this, select the disk in question and another disk from the vg it should be associated to and run:

echo "0x2008?4D"

Take a look at that last column-if they are the same then just vgexport & import...but if you pvcreated, then you should see they are different, and this is what you need to fix.
[You may also have to deal with data that could have been affected on this disk, but that is another matter].

You can try to restore this information by using the vgcfgrestore. Here is what HP suggested we try when something 'similar' happened here, you may have to throw in a vgchange -c n:

stop the db
umount all fs in /dev/vgwc (volume group)
vgchange -a n /dev/vgwc
vgcfgrestore -n /dev/vgwc /dev/rdsk/c0t5d0
vgchange -a e /dev/vgwc

remount & ck using echo command to see if disks now on same vgid...

mount all fs in /dev/vgwc volume group
----it worked for us----

We also had this happen on a 'root' disk once and got it fixed...a little more involved because we had to clear those first 4 blocks that were now wrong and then get it restored.

Hope it helps,
Rita

[Rita C Workman]

..oops type...the command should be:

echo "0x2008?4D" | adb /dev/dsk/c-t-d-

..where c-t-d- is the disk in question & the other good disk in the vg you choose.

Sorry !
Rita

[Walter Goncalves]

Thanks all.

I will try your suggestions tonight.

[Rita C Workman]

..here's another point. You may need to check as to which vg.conf you use. Remember you want to restore from the vg.conf that was good - and sometimes that is the old vg.conf.

Rgrds,
Rita

[Prashant Zanwar_4]

The disk which you have misused, I am not sure what operation you have performed on it. But certainly it is not identifying the volume group it is belonging to.
If safe, you can restore the VG configuration on the disk.

You will have a VG config in /etc/lvmconf/vgxx.conf..

What you have to try is, there is already the VG config present on your failover node..so is the VG config.
Do vgcfgrestore -F /etc/lvmconf/vgxx.conf
Do
Do a vgexport of your VG.
And use a previously created map file for importting.
vgimport -s -m ....

Hope this helps
Prashant