/etc/lvmconf

[Chuck Coar]

How are vg config files created? Is it safe to remove them if the vg's are no longer being used and have been vgexported? Where can I find more information regarding them?

Thank you,
Brent

[Rita C Workman]

I would not recommend just deleting files. One reason being that the /etc/lvmtab would still exist and all this could cause some confusion to the system (I would think..)
Generally, if you want to get rid of vg no longer in use. You would remove the logical volumes then the vg. This would make for a cleaner reduction. This will then reconfigure your vgcfg properly. When you've got everything cleaned up, you could then pvcreate the volumes too.
So you might want to review the manpages on lvremove and vgremove..

/rcw

[Darrel Louis · Accepted solution]

Jason,

The vg00.conf etc files are created or updated when you make modifications within a VG.

If you have a VG, which has been removed, you can remove the conf file.

The conf files are used with the vgcfgrestore command, see man vgcfgrestore.

You can update the conf files with vgcfgbackup command

Good Luck

Darrel

[Chuck Coar]

Thank you for the response. Here is my situation. We originally brought up a test instance on this box. However, we recently moved our test instance to a diffenent server. I am a bit confused, we have vg config files on the original server for all of our vgtst's. But the server which our tst instance is now running does not have any vg config files in /etc/lvmconf. Should they exist on this server(where test instance is currently running)? Any thoughts? FYI, we have an EMC 8730 disk array.

[Anthony deRito]

Whenever you modify the configuration of a volume group, vgcfgbackup and lvlnboot are performed automatically. The vgcfgbackup will update the configuration based on the changes you made into a backup configuration file for that volume group. That backup configuration file is located in /etc/lvmconf.

Lets say for some example you have a more than half the disks in a (non-bootable) volume group that have failed. When you attempt to activate this volume group with the "vgchange -a y" command, the following message would be generated:

"Couldn't activate volume group "/dev/vgnn": Quorum not present, or some physical volume(s) are missing."

After you replace the bad disks, you still need to consider the LVM layout on the disks. In short, the layout consists of the following:

PVRA
VGRA
User Data Area
BDRA

The PVRA and the VGRA need to exist on ALL physical disks in the volume group because they contain information about the disks as it relates to its volume group to which the disk belongs. Back to our example, these headers will no longer exist on the disks you have replaced. The backup LVM configuration file in /etc/lvmconf is your saftey net for this issue. The vgcfgrestore command will nicely replace these headers on your replaced disks and allow you to once again activate the volume group. You can imagine this effort would be less "simple" without the backup files.

There should be no administration on your part to manage the contents of this directory other than to be sure you have the most recent information possible. Even this process is automatic every time you run a LVM command.

Hope this helps,

Tony

[Darrel Louis]

Jason,

How did you create the VG's on your current test server?

When you run "vgcfgbackup -u /dev/vg??" does it create the files in /etc/lvmconf?

Regards

Darrel

[Chuck Coar]

Darrel:
1) Exported mapfiles from serv1 (original tst)
2) ftp mapfiles to serv2 via ascii mode
3) mkdir/mknod on serv2 for each vg
4) imported mapfiles on serv2
5) umounted tst filesystems on serv1
6) deactivated vg on serv1
7) activated vg on serv2
8) mount all filesystems on serv2
That is the vg part of the move.

I ran the vgcfgbackup and it returned the folling error message "Configuration file "/etc/lvmconf/vgtstapp01.conf" not found or is corrupted". There are no config files for tst on serv2.

Thanks

[Peggy Fong]

Hi Jason,
Your steps look fine. But you don't say if your vgexport/vgimport was done with or without the -s option. Let's say you did your vgexport with the map file and you specfied all the disks. Then the error might indicate that you used the "u" option on the vgcfgbackup, which would not work since there is no /etc/lvmconf/{vg_name}.conf file, or all the disks are not available that should be there.

If you figure it out - plz post the solution. It is an interesting situation. Thanks.
Peggy

[Chuck Coar]

Peggy:
Here is an example of the vgimport command used.

vgimport -m vgtstapp01.mapfile -v /dev/vgtstapp01 /dev/dsk/c8t13d6

As to the /etc/lvmconf/{vgXX.conf), there currently are not any vgXX.conf files for test in this directory.

Thanks

[Peggy Fong]

Jason
Anthony's reply is excellent. When you vgimport a vgcfgbackup is not automatically done as it is for other commands (you probably know that since you ran the vgcfgbackup command). I have to admit I haven't seen that error, but I would suspect that you have the wrong disk. When you vgimport on another system (which needs access to the disks from the first system) you can specify some of the disks and I have in fact specified an incorrect disk that had some LVM on it).

To test - go back to the original system and do the export using the -s option to creat your map file. Then go to the system with the problem and vgimport with the -s option. This will scan all disks that are available and look for the VGID in the mapfile and import the disk that matches. If it is a different name than the one you used - that would be the problem. You should then be able to do a vgcfgbackup.

The reason I suspect this, is because vgimport must look at the disk you specifiy to import and even if the import worked if there is really know vg data there, then vgcfgbackup probably would not work.

[Chuck Coar]

Thanks for all of your help. Problem is solved. Simple overlook. When I brought tst over to serv2, I did not run vgcfgbackup, so the conf files in /etc/lvmconf where never created. I have now created them and now the vgcfgbackup -u (update) now works fine. Thanks for everyone's help. I will rm conf from serv1 and create them on serv2 (where they belong).

[Henry Weldon]

I would recommend you setup a cron job to routinely backup the LVM configuration files and create map files too. Here is a script that I use.