vgcfgrestore

[placitasmd]

I am geting an error when trying to do a vgcfgrestore that says 'too many argumnets'. The syntax of my command is vgcfgrestore -n /dev/vgXX /dev/rdsk/c2t1d0 /dev/rdsk/c2t2d0 /dev/rdsk/c2t3d0...../dev/rdsk/c3t2d0. This is occurring on a system that we are using to test DR. System configured with a VA7100 disk array, that has three volume groups all containing raw logical volumes. Ignited the system, and replaced the VA array with a spare VA so that we would not corrupt any data from the original array. Created all the LUNS via VFP prior to booting from ignite tape. ioscan see all the luns. Had issues with serial numbers being different, but was able to solve that. /etc/lvmtab does not know about the volume groups on the array, but /etc/lvmconf has entries for all of them. vgscan does not add them into /etc/lvmtab because they are not LVM drives yet. So, is it possible to do a vgcfgrestore to a volume group on a VA7100 disk array?

[Patrick Wallek]

That should work, but need to specify only 1 device at a time on your command line.

You could write a small script to do this:

#!/usr/bin/sh
for i in c2t2d0 c2t3d0 #specify all your device files here.
do
vgcfgrestore -n /dev/vgXX /dev/rdsk/${i}
done

[Joseph Loo]

Hi,

The vxcfgrestore command with -n option does not allow listing the device files. Try this:

# vgcfgrestore -n /dev/vgXX -l
which should list the physical volumes in the volume group.

# man vgcfgrestore
for more information.

Yes, it is possible to perform vgcfgrestore on the mentioned disk array.

Regards.

[placitasmd]

I have tried both methods with no success. When trying to do a vgcfgrestore with only one device, the command responded fine, but in reality it did nothing. It indicated that the volume group was not in /etc/lvmtab, and that it created it, but it never would. As for listing the devices from the lvmconf file, the lsit out just fine.

[Marco Santerre]

Mark,

what seems to be happening in this case is that you don't have anything defined in your /dev/ directory at all. So even though vgcfgrestore does work, all it is doing is putting the VGRA on the disk, your VG not being know to your system may well be your problem. Since this is for DR, I would recommend another approach which would be for you to build a little script to "capture" all your LVM info on your source server and re-create that LVM structure on your DR server. But this is only an opinion.

[placitasmd]

My dev directory is fully in tact. The make recovery restored all of that, but for some reason it did not restore lvmtab.

[Jean-Louis Phelix]

Mark,

I'm not sure to understand why you want to vgcfgrestore the disks. If they are copies of another volume, then the lmv structures are already present. You just have to import the volume. If the new system is in the same cluster as the other one, also use vgchgid command to change the vgid. But the right command for you is vgimport I think, not vgcfgrestore.

Regards.

[placitasmd]

I need to restore because my data does not exist. We replaced the original VA7100 with a new one that has no data or LVM info on it. All I have done to the new VA7100 is create LUNs that are identical to the VA7100 we removed.

[Jean-Louis Phelix]

OK ...

In this case, you could create a new dummy vg (pvcreate the disks, vgcreate) then cfgrestore one disk at a time to get back the old lv structure.

Regards.

[Todd McDaniel_1]

Unless I have totally misread your post... this is what you need to do.

First of all, You can't vgcfgrestore disks with info from a VG to disks which are not in any VG to begin with...you must vgimport the VGs...

Second, I dont believe you will need to vgcfgrestore b/c after you do the vgimport it will all be there...on your system.

I hope you created them with the vgexport -s option to attach a header to the disks for easy importing... however, you dont have to have that option defined as long as the /dev/dsk names can be made the same on the new host... otherwise I would re-export them with the -s option... it will save you a LOT of headaches... believe me the -s option is an awesome way to vgexport from one box and then reimport to another host.



Now, Okay so you say you have:

"pvcreated the disks...and that vgscan doesnt recognize them"... and "lvmtab doesnt know about the VGs on the array...

When you say "created the LUNS" what does that mean??" pvcreate? if so you just wiped out your data...

To the vgscan question. How could it rebuild them, you haven't imported them yet... The reason vgscan doesn't see them is b/c you haven't created any VGs as yet on the new disks...

__________
__________

Bottom line is this::

I agree with Jean-louis...

You need to peform a vgimport of the VGs so that lvmtab will see them.

mkdir
mknod
vgcreate -v -m /etc/lvmconf/*.mapfiles /dev/vgXX

mount

then make sure you set the proper mount options.

You just had a few steps out of order is all.

[Dietmar Konermann · Accepted solution]

OK... I will also try to add my suggestion. :) You have a new VA with the same LUN configuration as your old VA. You have /etc/lvmconf/*.conf files. So essentially all you need to do is:

1) Restore the LVM structures on the LUNs:

for i in /dev/rdsk/c2t1d0 ... ; do
vgcfgrestore -f /etc/lvmconf/vgXX.conf $i
done

2) Import the VG:

mkdir /dev/vgXX
mknod /dev/vgXX/group c 64 0xXX0000
vgimport vgXX /dev/dsk/c2t1d0 ...

Just my 2 cents...
Dietmar.

[placitasmd]

Hi Deitmar, I think you are heading me in the right direction. I do have another question though. The customer did not use sequential naming convention on there logical volumes, but I do have the names of all logical volumes, and the order they appear from within vgdisplay. So can I create a map file, and then use that as part of my vgimport command to restore the logical volume structure for the volume group. I do not expect to restore any data, just all the LVM info.

[Dietmar Konermann]

Yes, you can either create a mapfile manually for vgimport or simply rename the lvol's device special files after importing the VG. Be care to respect the naming convention, of course.

Best regards...
Dietmar.

[Tim D Fulford]

To extend what Dietmar said..

# mkdir /dev/vgXX
# mknod /dev/vgXX/group c 64 0x??0000
# vgimport /dev/vgXX /dev/dsk/cXtYdZ /dev/dsk/...

If you have the map file (actually a backup of /dev/vgXX before the system went band would do... but that is another story)
vgimport -m /dev/vgXX /dev/dsk/cXtYdZ /dev/dsk/...

Regards

Tim

[placitasmd]

I appreciate all the responses. I am going to try this on Thursday or Friday of this week. Since I still have all the info in /dev/vgXX, I suspect that I will not need to recreate that, just do the vgcfgrestore followed by a vgimport. I guess that the vgimport command could or could not have the map file included in it.

[Jean-Louis Phelix]

Hi,

I full agree that a vgimport would be nice. But you *need* to have the lvm structures on the disks. I think that you forgot the initial problem : you cannot vgcfgrestore if the vg is not yet in the lvmtab with its disks. That's why I proposed to first create a dummy one with required disks THEN vgcfgrestore, vgexport and vgimport.

Regards.

[Jean-Louis Phelix]

Hi,

Sometimes too tired ... sometime still half asleep ... Of course Dietmar is right and you can restore the lvm structure without having the disk in the lvmtab. Sorry !

Regards.

[placitasmd]

I would like to thank everyone for there assistance with this issue. After doing the vgcfgrestore, and the vgimport with a configuration file from /etc/lvmconf, I was successful in recovering the system. THANKS!!!