Why did I loose vg02?

[Charles Holland]

As part of our normal monthy proces we make ignite backups on the 1st and 3rd Saturdays of the month. Recently we were working with trying to recover a K560 from an ignite server. When we were FINALLY successful in recovering the back up we had no vg02 and had to do a vgscan, vgimport for all the disks and vgchange to activate them.

Reviewing the > backup < script output :

______________________________________________________________

Command line=
make_net_recovery -v -s private_rp5450 -a private_rp5450:/ignite/recovery/archives/sandbox -n 3 -x inc_entire=vg00 -x exclude=/tmp -x exclude=/var/tmp -P s -d Archive_of_SANDBOX

______________________________________________________________
* Creating NFS mount directories for configuration files.
* Recovery Archive Name = 2005-06-18,00:36

* Lanic Id = 0x080009D8D0FD

* Ignite-UX Server = private_rp5450


======= 06/18/05 00:36:34 EDT Started make_net_recovery. (Sat Jun 18 00:36:34
EDT 2005)
@(#) Ignite-UX Revision B.5.4.50
@(#) net_recovery (opt) $Revision: 10.637 $

* Testing pax for needed patch
* Passed pax tests.
* Recovery Archive Description = Archive_of_SANDBOX

* Recovery Archive Location =
private_rp5450:/ignite/recovery/archives/sandbox

* Number of Archives to Save = 3

* Pax type = tar


In? dsk/vg name minor# Associated disks/mountpoints
0 v /dev/vg01 0x01 /dev/dsk/c1t0d0 /dev/dsk/c9t0d0
/dev/vg01/lvol1 /sapdb 0
/dev/vg01/lvol2 /usr/sap/PRD 0
/dev/vg01/lvol3 /sapdb_backup0 0
-1 v /dev/vg02 0x02 /dev/dsk/c1t1d0 /dev/dsk/c9t1d0 /dev/dsk/c1t2d0 /dev/dsk/c9t2d0 /dev/dsk/c1t3d0 /dev/dsk/c9t3d0 /dev/dsk/c1t4d0 /dev/dsk/c9t4d0 /dev/dsk/c1t5d0 /dev/dsk/c9t5d0 /dev/dsk/c1t6d0 /dev/dsk/c9t6d0 /dev/dsk/c1t7d0 /dev/dsk/c9t7d0 /dev/dsk/c1t8d0 /dev/dsk/c9t8d0 /dev/dsk/c1t9d0 /dev/dsk/c9t9d0
/dev/vg02/lvol01
/dev/vg02/lvol02
/dev/vg02/lvol03
/dev/vg02/lvol04
/dev/vg02/lvol05
/dev/vg02/lvol06
/dev/vg02/lvol07
/dev/vg02/lvol08
/dev/vg02/lvol09
/dev/vg02/lvol10
/dev/vg02/lvol11
/dev/vg02/lvol12
/dev/vg02/lvol13
/dev/vg02/lvol14
/dev/vg02/lvol15
/dev/vg02/lvol16
/dev/vg02/lvol17
/dev/vg02/lvol18
/dev/vg02/lvol19
/dev/vg02/lvol20
/dev/vg02/lvol21
/dev/vg02/lvol22
/dev/vg02/lvol23
/dev/vg02/lvol24
/dev/vg02/lvol25
/dev/vg02/lvol26
/dev/vg02/lvol27
/dev/vg02/lvol28
/dev/vg02/lvol29
/dev/vg02/lvol30
/dev/vg02/lvol31
/dev/vg02/lvol32
/dev/vg02/lvol33
/dev/vg02/lvol34
1 v /dev/vg00 0x00 /dev/dsk/c2t4d0 /dev/dsk/c2t5d0 /dev/dsk/c2t6d0
/dev/vg00/lvol1 /stand 2
/dev/vg00/lvol2
/dev/vg00/lvol3 / 2
/dev/vg00/lvol4 /home 2
/dev/vg00/lvol5 /opt 2
/dev/vg00/lvol6 /tmp 0
/dev/vg00/lvol7 /usr 2
/dev/vg00/lvol8 /var 1
* Checking Versions of Recovery Tools
* Creating System Configuration.
* /opt/ignite/bin/save_config -f /var/opt/ignite/recovery/client_mnt/0x0
80009D8D0FD/recovery/2005-06-18,00:36/system_cfg vg00
* Backing Up Volume Group /dev/vg01
* /usr/sbin/vgcfgbackup /dev/vg01 Volume Group configuration for /dev/vg01 has been saved in /etc/lvmconf/vg01.conf
* Creating Map Files for Volume Group /dev/vg01
* /usr/sbin/vgexport -p -m /etc/lvmconf/vg01.mapfile /dev/vg01
vgexport: Volume group "/dev/vg01" is still active.

* Backing Up Volume Group /dev/vg00
* /usr/sbin/vgcfgbackup /dev/vg00 Volume Group configuration for /dev/vg00 has been saved in /etc/lvmconf/vg00.conf
* Creating Map Files for Volume Group /dev/vg00
* /usr/sbin/vgexport -p -m /etc/lvmconf/vg00.mapfile /dev/vg00
vgexport: Volume group "/dev/vg00" is still active.

* Creating Control Configuration.
* Creating Archive File List
* Creating Archive Configuration

* /opt/ignite/bin/make_arch_config -c /var/opt/ignite/recovery/client_mn
t/0x080009D8D0FD/recovery/2005-06-18,00:36/archive_cfg -g /var/opt/ign
ite/recovery/client_mnt/0x080009D8D0FD/recovery/2005-06-18,00:36/flist
-n 2005-06-18,00:36 -r 64 -d Archive_of_SANDBOX -L
/var/opt/ignite/recovery/arch_mnt -l
private_rp5450:/ignite/recovery/archives/sandbox -i 1 -m t
* Saving the information about archive to
/var/opt/ignite/recovery/previews
* Creating The Networking Archive

* /opt/ignite/data/scripts/make_sys_image -d
/var/opt/ignite/recovery/arch_mnt -t n -s local -n 2005-06-18,00:36 -m
t -w /var/opt/ignite/recovery/client_mnt/0x080009D8D0FD/recovery/2005-
06-18,00:36/recovery.log -u -R -g /var/opt/ignite/recovery/client_mnt/
0x080009D8D0FD/recovery/2005-06-18,00:36/flist -a 3368460

* Preparing to create a system archive
* The archive is estimated to reach 1684230 kbytes.
* Free space on /var/opt/ignite/recovery/arch_mnt
after archive should be about 35225682 kbytes.

* Archiving contents of sandbox via tar to
/var/opt/ignite/recovery/arch_mnt/2005-06-18,00:36.
* Creation of system archive complete

* Creating CINDEX Configuration File

* /opt/ignite/bin/manage_index -q -c 2005-06-18,00:36\ Recovery\ Archive
-i /var/opt/ignite/recovery/client_mnt/0x080009D8D0FD/CINDEX -u
Archive_of_SANDBOX

* Cleaning up Archives
NOTE: Archive: 2005-05-07,00:36 is being deleted
* /opt/ignite/bin/manage_index -d -c 2005-05-07,00:36\ Recovery\ Archive
-i /var/opt/ignite/recovery/client_mnt/0x080009D8D0FD/CINDEX

======= 06/18/05 01:29:32 EDT make_net_recovery completed successfully!


A bit hard to read, sorry. But I note that on the vg02 information line, under the In? column, it has a entry of -1. I can find in the admin guide what a 0,1,2 represent but no - numbers. Other than "sorry you won't be able to recover this volumn group" ( a guess on my part) what caused this, and more importantly how do I resolve this for the future? Please not as part of the process it did a vgcfgbackup for both vg00 and vg01 but not vg00.

Any help would be appreciated and I do assign points.

Thanks

[MarkSyder]

The best resolution is only to use ignite for vg00, which is what it's designed for - it really isn't very good for backing up non-operating system stuff.

Better to use something like fbackup or Data Protector for vg01 and vg02 - daily rather than twice a month.

Mark Syder (like the drink but spelt different)

[Pete Randall]

Your answer lies in the command you used to create your archive:

make_net_recovery -v -s private_rp5450 -a private_rp5450:/ignite/recovery/archives/sandbox -n 3 -x inc_entire=vg00 -x exclude=/tmp -x exclude=/var/tmp -P s -d Archive_of_SANDBOX

Note the "-x inc_entire=vg00" portion. If you wanted to include other VGs, they would have to be identified similarly. Note also that this is outside of Ignite's intended scope. While it can be done, it is not recommended.


Pete

[Devender Khatana]

Hi,

It is required for all the VG's which were not included in the backup. This is usual & the actual purpose of ignite backup is to recover system from boot disk failures & not any other faiures in other VG's. So use other methods of backup for other VG's & ignite for backing up vg00. This will make your recovery fast when vg00 disk fails & will not require to recover when disk in some other VG fails.

HTH,
Devender

[harry d brown jr]

You didn't specify vg02 or even vg01 in the backup:

make_net_recovery -v -s private_rp5450 -a private_rp5450:/ignite/recovery/archives/sandbox -n 3 -x inc_entire=vg00 -x exclude=/tmp -x exclude=/var/tmp -P s -d Archive_of_SANDBOX

where you should specify vg02 and vg01 specifically:

make_net_recovery -v -s private_rp5450 -a private_rp5450:/ignite/recovery/archives/sandbox -n 3 -x inc_entire=vg00 -x exclude=/tmp -x exclude=/var/tmp -x inc_entire=vg01 -x inc_entire=vg02 -P s -d Archive_of_SANDBOX

I don't know why it backed up vg01, but it did (huh!).

What does this command return?

what `which make_net_recovery`

live free or die
harry d brown jr

[melvyn burnard]

One question to ask, was vg02 activated at the time of creating the recovery archive?
If not, and you are using version 5.4 or below of Ignite, then it will NOT backup the information for the deactivated vg's.
This is a standard problem for servers that are memners of a Serviceguard cluster, and this issue has been fixed in the 6.x release of Ignite.

Just a thought.

[Charles Holland]

First I wish to thank everyone for their quick replies. Although I must confess I don't understand the answers to some of them. First off I understand what make_net_recovery is supposed do. Back up vg00, with the options to include other vg's in it if you want to.

In most everyones response it is assumed that I want to back up vg01 and vg02 using make_net_recovery. Let me make this clear..I do not want to back up > ANYTHING < except VG00
in this proces. Yes Mark we already to use fbackup or Data Protector to take care of the vg01 and vg02 data.

By a man page on make_net_rrecovery :
-x inc_entire=/dev/dsk/|vg_name
Includes all file systems contained on the specified disk or volume group. Use a block device file of the format /dev/dsk/ when specifying a whole-disk (non-LVM) file system. Use the volume group name (such as vg00) when you want all file systems that are part of that LVM volume groupto be included in the archive.

That is why I specifically specified "-x inc_entire=vg00" in the command line.

Harry - I scanned through the flist file that
is located at /var/opt/ignite/clients/sandbox/recovery/latest and there is NOTHING in it other than vg00 file structure, do I have to presume that it didn't back up anything in any other vg.

In regards to your what command the results are
# what `which make_net_recovery`
/opt/ignite/bin/make_net_recovery:
Ignite-UX Revision B.5.4.50
net_recovery (opt) $Revision: 10.637

Yes I know I'm a bit behind, tried to dowload 6.1.44 this morning by service was not available at that time.

Melvyn - Yes vg02 was activated at the time of creating the archive. In vg02 is where our database (raw file system) resides. As you can see above it is version 5.4 but there is no Serviceguard involved (don't have it).

I have just been able to download the new version of ignite. Can someone advise if I have to uninstall the 5.4 version from all the clients and the Ignite server first and then install the 6.1.44 version, or (I hope) simpley install it on all servers and be done with it.

Still looking for answers why vg02 had to recreated by hand. Or better yet why the backup procedure recognized the existance of vg02 but did not run a vgcfgbackup on it.

Regards

[Steven E. Protter]

What Ignite is good at:

Getting a good image of your boot volume group, usually vg00

What Ignite can not do:
Get an image of an open database like oracle and such.

When you get your vg00 image it should include the setup for all the other volume groups within that Ignite image.


Hopefully this simplification will be useful. You are getting excellent help here.

SEP

[Pete Randall]

Charles,

I don't believe vg01 was backed up either. The only thing it did was run vgcfgbackup against it. Can you examine your archive to see if anything of vg01 was backed up?


Pete

[Charles Holland]

SEP - I just reviewed the other 2 systems that have a database on them and they also had the "-1" in the In? column. In both cases it identified the existance of the vg and listed the disks in the vg but did not run a vgcfgbackup process on it. I agree with you that it should have the setup for all the other vg's also. But it apparently didn't as we had to go through the above process to get it back.

Pete - see above the answer to Harry about looking at the flist file.

Regards.

[Charles Holland]

Is it possible that there is no filesystem data on this vg that it is causing this problem?

[Charles Holland]

Typo problem "that there is > no < file system"

[harry d brown jr]

man make_net_recovery

/var/opt/ignite/clients/0x{LLA}/recovery/config.local
An optional config file that the user may create to add configuration information to be used during the recovery of the client. For example, you may want to add to this file a post_config_cmd to re-mirror disks that the recovery process un-mirrored. (See the document:
/opt/ignite/share/doc/diskmirror.pdf for an example). Once this file is created, make_net_recovery will automatically add it to any new configurations that it adds to the CINDEX file.

make_net_recovery will NOT re-create mirror groups, nor build other vg's.



what is the output of the following commands?

strings /etc/lvmtab

cat /etc/fstab

ls -l /etc/lvmconf


live free or die
harry d brown jr

[Charles Holland]

Harry,

# strings /etc/lvmtab
/dev/vg00
/dev/dsk/c2t6d0
/dev/dsk/c2t5d0
/dev/dsk/c2t4d0
/dev/vg01
/dev/dsk/c1t0d0
/dev/dsk/c9t0d0
/dev/vg02
/dev/dsk/c1t1d0
/dev/dsk/c1t2d0
/dev/dsk/c1t3d0
/dev/dsk/c1t4d0
/dev/dsk/c1t5d0
/dev/dsk/c1t6d0
/dev/dsk/c1t7d0
/dev/dsk/c1t8d0
/dev/dsk/c1t9d0
/dev/dsk/c9t1d0
/dev/dsk/c9t2d0
/dev/dsk/c9t3d0
/dev/dsk/c9t4d0
/dev/dsk/c9t5d0
/dev/dsk/c9t6d0
/dev/dsk/c9t7d0
/dev/dsk/c9t8d0
/dev/dsk/c9t9d0

# cat /etc/fstab
# System /etc/fstab file. Static information about the file systems
# See fstab(4) and sam(1M) for further details on configuring devices.
/dev/vg00/lvol3 / vxfs delaylog 0 1
/dev/vg00/lvol1 /stand hfs defaults 0 1
/dev/vg00/lvol4 /home vxfs delaylog 0 2
/dev/vg00/lvol5 /opt vxfs delaylog 0 2
/dev/vg00/lvol6 /tmp vxfs delaylog 0 2
/dev/vg00/lvol7 /usr vxfs delaylog 0 2
/dev/vg00/lvol8 /var vxfs delaylog 0 2
/dev/vg01/lvol1 /sapdb vxfs rw,suid,nolargefiles,delaylog,datainlog 0 2
/dev/vg01/lvol2 /usr/sap/PRD vxfs rw,suid,nolargefiles,delaylog,datainlog 0 2
/dev/vg01/lvol3 /sapdb_backup0 vxfs rw,suid,largefiles,delaylog,datainlog 0 2

>> YEP there is nothing there for vg02 <<

# ls -l /etc/lvmconf
total 3248
---------- 1 root sys 0 Oct 18 2004 lvm_lock
-rw------- 1 root sys 323584 Jun 21 15:35 vg00.conf
-rw------- 1 root sys 323584 Jun 18 00:37 vg00.conf.old
-rw-r--r-- 1 root sys 64 Jun 18 00:37 vg00.mapfile
-rw------- 1 root sys 584704 Jun 21 15:35 vg01.conf
-rw------- 1 root sys 584704 Jun 18 00:37 vg01.conf.old
-rw-r--r-- 1 root sys 24 Jun 18 00:37 vg01.mapfile
-r-------- 1 root sys 314368 Jan 24 13:41 vg02.conf
-r-------- 1 root sys 314368 Jan 24 13:41 vg02.conf.old

Hope this gives some information.

[Charles Holland]

Well, guess I'm on my own.

[MarkSyder]

No, you're not on your own. I think those of us with a reasonable knowledge (such as myself) were waiting for someone with a good knowledge to answer! But they haven't, so I'll have a go.

It looks as though the problem is in /etc/fstab - there should be entries there for vg02.

Have you checked the date on the file? Backup copies?

I'm sure there's a way to regenerate the fstab file correctly - there must be someone out there who knows what it is.

Mark

[Pete Randall]

To fix /etc/fstab, you just edit it. According to the man page:

"fstab is an ASCII file that resides in directory /etc. Programs read it, but do not write to or from it. System administrators are responsible for creating and maintaining this file properly."


The other issue might be with /etc/mnttab. After you fix your fstab, do a mount -a to straighten out the mnttab. That should do it.


Pete

[Charles Holland]

Welcome back Mark and Pete.

There are no entries in the /etc/fstab for vg02 because there are no "mountable file systems" in that volumn group. Everything in that vg is assigned to the database which is accessed through the raw logical volumns threfore no need of having entries in /etc/fstab.

When we were using Informix as the db of choice it also used raw access. The db we are currently using (SAPDB) also uses raw access.

As stated earlier I don't expect make_net_recovery to back up or restore the data on my database. If the /etv/lvmtab had been simply restored from the backup I *suspect* everthing would have been fine.

But I wonder why the backup (make_tape_recovery) ran a vgcfgbkup on ONLY the ones that had entries in the /etc/fstab. Apparently no entreies in /etc/fstab = no vgcfgbkup run.

I just went and looked at the /var/opt/ignite /clients/sandbox/manifest file and it has the following :

LVM_LAYOUT /dev/vg00: " " " " " "
LVM_LAYOUT /dev/vg00/lvol1 /stand 504 hfs
LVM_LAYOUT /dev/vg00/lvol2 swap 1024 " "

LVM_LAYOUT /dev/vg01: " " " " " "
LVM_LAYOUT /dev/vg01/lvol1 /sapdb 800 vxfs
LVM_LAYOUT /dev/vg01/lvol2 /usr/sap/PRD 600 vxfs

LVM_LAYOUT /dev/vg02: " " " " " "
LVM_LAYOUT /dev/vg02/lvol01 " " 1024 unused
LVM_LAYOUT /dev/vg02/lvol02 " " 1024 unused
LVM_LAYOUT /dev/vg02/lvol03 " " 1024 unused

Interesting........... It apparently thinks it has no data on it (no entries in /etc/fstab) so why recreate the vg.

Comments?

[Pete Randall]

Charles,

I think you're on exactly the right track. It (Ignite) sees no filesystems, so it thinks it's unused and ignores it. SAM would most likely report it as "unused" as well.


Pete

[Charles Holland]

Pete - yes it does show up as unused. I suspect that SAM reads the /etc/fstab also.

If you go into sam -> disks and file systems -> volume groups it reports 9 physical devices and 34 logical volumns.

If you go into sam -> disks and file systems -> Logical volumes it lists every logical volumn as being unused

If you go into sam -> disks and file systems ->
Disk Devices it lists each disk in the vg

Maybe upgrading to 6.1.44 will resolve all my problem.... or open another can of worms..

[Pete Randall]

Charles,

A quick review of the Release Notes ( http://www.docs.hp.com/en/IUX/whatsnew.html ) does not seem to indicate that this is something that has been addressed. I expect that you will continue to have to vgscan, vgimport and vgchange for these raw logical volumes. The one thing that might help is to run vgexport in preview mode, saving the map file on a filesystem that will get backed up:
vgexport -p -s -m /var/tmp/vg02.map /dev/vg02

Then, when it comes to time to rebuild, you should be able to just run your vgimport:
vgimport -s -m /var/tmp/vg02.map /dev/vg02

Good luck.


Pete

[Charles Holland]

Pete - I guess something like that is what I will have to do by hand. Eventhough it is done automatically for the other vg's (please see my original posting). Maybe I should call HP software support and raise the flag with them.

Regards

[A. Clay Stephenson]

My outbushwhack it approach would be to add a very small LVOL to vg02 (please tell me that you didn't use all the space in the VG), create a filesystem on it, and put the entry in /etc/fstab. The danger to automatically importing and activating this VG would occur in a ServiceGuard environment. My preference is to only use Ignite for vg00 and I'll take care of everything else including any needed vgimports.

[Charles Holland]

Sorry A Clay... sure did use it all....

Anyway update after upgrading to 6.1.44 verion of Ignite.

In? dsk/vg name minor# Associated disks/mountpoints
1 v /dev/vg00 0x00 /dev/dsk/c2t6d0 /dev/dsk/c2t5d0 /dev/dsk/c2t4d0
/dev/vg00/lvol1 /stand 2
/dev/vg00/lvol2
/dev/vg00/lvol3 / 2
/dev/vg00/lvol4 /home 2
/dev/vg00/lvol6 /tmp 0
/dev/vg00/lvol8 /var 1
/dev/vg00/lvol5 /opt 2
/dev/vg00/lvol7 /usr 2
0 v /dev/vg01 0x01 /dev/dsk/c1t0d0 /dev/dsk/c9t0d0
/dev/vg01/lvol1 /sapdb 0
/dev/vg01/lvol2 /usr/sap/PRD 0
/dev/vg01/lvol3 /sapdb_backup0 0
0 v /dev/vg02 0x02 /dev/dsk/c1t1d0 /dev/dsk/c9t1d0 /dev/dsk/c1t2d0 /dev/dsk/c9t2d0 /dev/dsk/c1t3d0 /dev/dsk/c9t3d0 /dev/dsk/c1t4d0 /dev/dsk/c9t4d0 /dev/dsk/c1t5d0 /dev/dsk/c9t5d0 /dev/dsk/c1t6d0 /dev/dsk/c9t6d0 /dev/dsk/c1t7d0 /dev/dsk/c9t7d0 /dev/dsk/c1t8d0 /dev/dsk/c9t8d0 /dev/dsk/c1t9d0 /dev/dsk/c9t9d0
/dev/vg02/lvol01
/dev/vg02/lvol02
/dev/vg02/lvol03
/dev/vg02/lvol04
/dev/vg02/lvol05
/dev/vg02/lvol06
/dev/vg02/lvol07
/dev/vg02/lvol08
/dev/vg02/lvol09
/dev/vg02/lvol10
/dev/vg02/lvol11
/dev/vg02/lvol12
/dev/vg02/lvol13
/dev/vg02/lvol14
/dev/vg02/lvol15
/dev/vg02/lvol16
/dev/vg02/lvol17
/dev/vg02/lvol18
/dev/vg02/lvol19
/dev/vg02/lvol20
/dev/vg02/lvol21
/dev/vg02/lvol22
/dev/vg02/lvol23
/dev/vg02/lvol24
/dev/vg02/lvol25
/dev/vg02/lvol26
/dev/vg02/lvol27
/dev/vg02/lvol28
/dev/vg02/lvol29
/dev/vg02/lvol30
/dev/vg02/lvol31
/dev/vg02/lvol32
/dev/vg02/lvol33
/dev/vg02/lvol34
/dev/vg02/lvol1
/dev/vg02/lvol2
/dev/vg02/lvol3
/dev/vg02/lvol4
/dev/vg02/lvol5
/dev/vg02/lvol6
/dev/vg02/lvol7
/dev/vg02/lvol8
/dev/vg02/lvol9
* Checking Versions of Recovery Tools
* Creating System Configuration.
* /opt/ignite/bin/save_config -f /var/opt/ignite/recovery/client_mnt/0x0
80009D8D0FD/recovery/2005-06-23,20:00/system_cfg vg00
* Backing Up Volume Group /dev/vg00
* /usr/sbin/vgcfgbackup /dev/vg00
* Creating Map Files for Volume Group /dev/vg00
* /usr/sbin/vgexport -p -m /etc/lvmconf/vg00.mapfile /dev/vg00

* Backing Up Volume Group /dev/vg01
* /usr/sbin/vgcfgbackup /dev/vg01
* Creating Map Files for Volume Group /dev/vg01
* /usr/sbin/vgexport -p -m /etc/lvmconf/vg01.mapfile /dev/vg01

* Backing Up Volume Group /dev/vg02
* /usr/sbin/vgcfgbackup /dev/vg02
* Creating Map Files for Volume Group /dev/vg02
* /usr/sbin/vgexport -p -m /etc/lvmconf/vg02.mapfile /dev/vg02


Differences that I note right off hand.
1. Under the In? column there is no "-1" for vg02. Everything is either a "0" or a "1".
2. It did run a vgcfgbkup for vg00, vg01 AND vg02.

Now the next thing is to declare a failure and see how it goes on the recovery side.

Always forward

[Charles Holland]

Aparently resolution was to upgrade to 6.1.44 version of Ignite. When recovered the vg02 volumn groups were automatically recognized, recovered, and activated.

Thanks to all....