Ignite doesn't bring back SAN Volume Groups

[jackie baron_1]

My Ignite server is working nicely and archives and restores a test client perfectly.

I then tried to archive the vg00 of another server that also had some volume groups on SAN disks.

The Ignite server created the vg00 archive perfectly.
It was then time to restore it.

It ran through all the phases (load software, build kernel, etc.) but failed at the post installation scripts.

The server came back up but with only vg00 restored. None of the other volume groups returned. It also seemed to blow them out of the /etc/lvmtab even though they're all still in the fstab. The device files are all still there.

Attached is a text file of bdf before and after and also the logfile extract from where it started failing.

Thanks for any help

j

[sujit kumar singh]

Hi Jackie,


u will need to include the other vgs also at the time of making the Archives.


while using the command line syntax of ceating the archives which include vg00 and other VG say vg01 also u need to do like this:

#make_net_recovery -v -x enc_entire=vg00 -x inc_entire=vg01 -x enc_entire=vgxx -s -s

While using GUI u shall get in the right side of screen where u can include the other VG.

Once ur Ignite image contains the archives of vg00 as well as the other VG(s) u will be surely prompted for the other VG configuratuions at the time of restoring the Clients using that Image.


Regards
Sujit

[Pete Randall]

I'm just think out loud here, but I have to wonder if you don't just need to import them. Check and see if the /dev entries are there already (/dev/vg01 and /dev/vg01/group, for example). Then you just have to run the vgimport. If the entries aren't there, just create them and then run the import. These steps could be put into the post installation scripts, I would think.


Pete

[Pete Randall]

Sorry - "thinking out loud"


Pete

[Avinash20]

NOTE: The data on SAN disk is not touched

# If you like to use the same disk on the SAN for this server, and if the disk are claimed, and if you are having the old /etc/lvmtab and could identify the disk to which vg it belong, you could well create the VG's directory again (mkdir /dev/vg01, mknod .. ) and do a vgimport with the disk.

If you are having the mapfiles(/etc/lvmconf/*.map), then you need to include -m with vgimport so that you could get the original lvol name instead of default lvol1,2...

[sujit kumar singh]

hello Jakie,


aloght mistake in the command in the earlier post please note that

#make_net_recovery -v -x enc_entire=vg00 -x inc_entire=vg01 -x enc_entire=vgxx -s -s


here actually shud be -d


Also if u have vg01(,vg02,.., vgxx) as included in teh make_net_archive, u will be gettting an opportunity to congigure the other VGs also and the size of the LVs while restoring that image on to the Client.


Regards
sujit

[sujit kumar singh]

hi


might be my earlie rreplies are far too away from what the post talks .... but jakie did u configure the other VGs and the disks to be used by them while u were restoring the image on to the client ...

assuming that ur ignite image had vg00 and other vgs included when the archive was being made.


REgards


sujit

[sujit kumar singh]

hi


did u choose the disks properly for the rootVG and the other VGs in the Ignite Restoration and OS install screen Filesystems Menu?

actually from the Filesystem TAB of the Ignite Restoration screen also u can get an opportunity of configuring the root VG and other VGs during the Ignite Install Screen on to the client.

just few questions


regards
sujit

[jackie baron_1]

Sujit you write "enc_entire" in your conmmand recommendation....

...is that correct syntax?

J

[likid0]

I should think, that you want to import the vgs/data on the san disks, not restore all the data from the ignite backup, otherwise you could finish with a gigantic ignite image.That would take ages to restore.

You should check on the ignite gui you check the import vgs option.

And then check the logs and have a look at why it has failed the post installation scripts.

[Eric SAUBIGNAC]

Bonjour Jackie,

As previously said by orange, don't deal with inc_entire other than vg00. That would produce a big image and the goal of ignite is not to save aplications and their datas. Just keep something like "make_net_recovery -x enc_entire=vg00 -s YourIgniteServer".

Back to your initial post :

"I then tried to archive the vg00 of another server that also had some volume groups on SAN disks.

The Ignite server created the vg00 archive perfectly.
It was then time to restore it."

--> Where did you restore this image ? On the original server ? Which kind of external storage are you using ? Did you modified something on the storage ?

Eric

[jackie baron_1]

Hi Eric / Sujit

OK I have an ignite server and I want to make an archive of a client. The client is on the same segment and is succesfully registered in the Ignite GUI on the server.

The client has a vg00 on an internal disk and a few other vg's on SAN disks.

I only want to archive the vg00 which is about 10GB. This I can do successfully. I run "make_net_recovery -s -x inc_entire=vg00" on the command line of the client and the archive is created and stored in /var/opt/ignite/recovery/archives/ directory on the Ignite Server.

When I then do a new install for the client (from the server GUI) and select the archive that I just created it restores the vg00 but when I execute bdf on the client once the restore is complete all filesystems in vg00 are there but none of the SAN volume groups have been mounted.

Does this make sense?

j

[Eric SAUBIGNAC]

Unless you have modified the file /var/opt/ignite/client//control_cfg, or modified storage configuration, HBA in the box, etc ... it has no sense following my knowledge. Please post "control_cfg"

Eric

[jackie baron_1]

Here is the control_cfg:

# more control_cfg
RECOVERY_MODE=TRUE
enum _HP_CLONING
_HP_CLONING help_text "Cloning to different HW?"
_HP_CLONING = { "TRUE", "FALSE" }
(MODEL == "9000/800/L3000-6x")
{ init _HP_CLONING = "FALSE" }
else
{ init _HP_CLONING = "TRUE" }

enum _IMPORT_VG
_IMPORT_VG help_text "Import the Volume Group(s)?"
_IMPORT_VG = { "TRUE", "FALSE" }
init _IMPORT_VG = "TRUE"
(_IMPORT_VG == "TRUE")
{
post_config_cmd = "
/usr/sbin/vgimport -v -m /etc/lvmconf/vgdata1.mapfile /dev/vgdata1 \
/dev/dsk/c10t0d0 \
/dev/dsk/c11t0d0 \
/dev/dsk/c6t0d0 \
/dev/dsk/c7t0d0 \
/dev/dsk/c10t0d5 \
/dev/dsk/c11t0d5 \
/dev/dsk/c6t0d5 \
/dev/dsk/c7t0d5
/usr/sbin/vgchange -a r vgdata1

/usr/sbin/vgimport -v -m /etc/lvmconf/vgdata2.mapfile /dev/vgdata2 \
/dev/dsk/c10t0d3 \
/dev/dsk/c11t0d3 \
/dev/dsk/c6t0d3 \
/dev/dsk/c7t0d3 \
/dev/dsk/c10t0d4 \
/dev/dsk/c11t0d4 \
/dev/dsk/c6t0d4 \
/dev/dsk/c7t0d4
/usr/sbin/vgchange -a r vgdata2

test -d /dev/vg00 && /usr/sbin/vgcfgbackup /dev/vg00
test -d /dev/vgdata1 && /usr/sbin/vgcfgbackup /dev/vgdata1
test -d /dev/vgdata2 && /usr/sbin/vgcfgbackup /dev/vgdata2
"}
else
{
post_config_cmd = ""
}

_hp_allow_use_of_imports help_text "Allow use of other disks"
enum _hp_allow_use_of_imports
init _hp_allow_use_of_imports = "NO"
_hp_hide_other_disks visible_if false
_hp_allow_use_of_imports = { "YES", "NO" }
(_hp_allow_use_of_imports == "NO")
{
_hp_hide_other_disks = "0/2/0/0.21.0.239.0.0.0
0/2/0/0.21.2.239.0.0.0
0/5/0/0.20.0.239.0.0.0
0/5/0/0.20.5.239.0.0.0
0/2/0/0.21.0.239.0.0.5
0/2/0/0.21.2.239.0.0.5
0/5/0/0.20.0.239.0.0.5
0/5/0/0.20.5.239.0.0.5
0/2/0/0.21.0.239.0.0.3
0/2/0/0.21.2.239.0.0.3
0/5/0/0.20.0.239.0.0.3
0/5/0/0.20.5.239.0.0.3
0/2/0/0.21.0.239.0.0.4
0/2/0/0.21.2.239.0.0.4
0/5/0/0.20.0.239.0.0.4
0/5/0/0.20.5.239.0.0.4"
} else {
_hp_hide_other_disks = ""
}

[Eric SAUBIGNAC]

Well,

Every thing is ready in this file to import external VG.

Now, from the box you have just installed with the ignite image, I mean the box where import of vg has failed, post in attachment "ioscan -fkn".

Eric

[jackie baron_1]

Eric, Guys,

The problem is that I can't use the ignite GUI on the Ignite server. I have X windows sending back the display to my desktop but it doesn't work when I try to create an ignite archive of my client machine's vg00.

The ignite client has 3 volume groups vg00, vgdata1 and vgdata2. vg00 is on an internal disk while vgdata1 and vgdata2 are on SAN disks.

Can ANYONE give me the command line syntax to be able to create an archive of this machine with all the data in vg00 but also not lose vgdata1 and vgdata2 information?

Sujit gave some command line stuff but it included stuff that I don't think is the right syntax (Enc_entire instead of Inc_entire).

When I run make_net_recovery -s -x inc_include=vg00
it creates the archive. When I go to the Ignite server and launch the GUI and do a new install to the client machine and select the archive I just created (with vg00) it restores is but a bdf on the newly ignited client machine only shows vg00 files systems.

[sujit kumar singh]

Hi Jackie,

That had been a big typo from me.
For your client that is "The ignite client has 3 volume groups vg00, vgdata1 and vgdata2. vg00 is on an internal disk while vgdata1 and vgdata2 are on SAN disks." The command shall be like that

#make_net_recovery -v -x inc_entire=vg00 -x inc_entire=vgdata1 -x inc_entire=vgdata2 -s -d




Regards
Sujit

[sujit kumar singh]

Hi Jakie,


the above command is supposed to crrate all the Image that will have all the data as wel as LVM configuration for all the three VGs that is vg00, vgdata1 and vgdata2.

after that go the client:

1)boot the client from the Ignite Server from the preferred method.
2)YOu remenber choosing /selecting the disks for the Root VG that vg00 at the time of the Ignite Installation of the Client? IN that way only you will need and you shall be able to choose/select the disks (From SAN)for creation of vgdata1 and vgdata2, You can also modify the LV sizes for the LVs in vgdata1 and vgdata2 as in VG Vg00


regards
sujit

[Eric SAUBIGNAC]

Bonsoir Jackie,

As previously said in an other thread, I have no many time to answer in forums this week. But I hate giving up a thread ...

As previously said, importing other vg than vg00 SHOULD work properly. The configuration file you have posted is clean.

So if it does not work I can sea some reasons :
- the box on wich you are trying to reinstall is not the same that the original one. That's why I asked you to post output of a full ioscan, and you did not ;-) But anyway, it doesn't seem to be the case
- some configuration has changed in the SAN (san switches, storage area, etc ..) between the moment you took the ignite image and the moment you tried to restore it. ioscan could also shows the differences if any ...
- you storage needs a multipathing solution and the devices you use to create the vg are totaly handled by this software. In this case at ignite time the multipathing layer is not active and in fact vg are not imported.

Did you try to import those vg manually, after ignite time ? It could give some informations that could explain why it did not work during installation. For example, are devices the same ?

Eric

[jackie baron_1]

Eric,

The machine I am trying to backup and restore is one and the same. I am the only one logged onto it so nobody is messing around with SAN information between the time I create the Ignite archive and the time that I restore it. Attached is a copy of the ioscan listing.

Sujit you give the command "make_net_recovery -v -x ince_entire=vg00 -x inc_entire=vgdata1 -x inc_entire=vgdata2" ....but won't this create a HUGE Ignite archive that includes ALL the data on the entire server? No?

Thanks for all help.

j

[Eric SAUBIGNAC]

Jackie,

As previously posted, DON'T use inc_entire on volume groups other than vg00. This will create a huge archive. "make_net_recovery -x inc_entire=vg00 -s YourIgniteServer" should be enough to import vgdata1 and vgdata2. The problem is to find why those volume groups are not imported at ignite time. And they should.

Well, I did a slight reconciliation between the files you have posted "control_cfg" and "ioscan" In ioscan I can find NO information about :
/dev/dsk/c10t0d5 (0/2/0/0.21.0.239.0.0.5)
/dev/dsk/c11t0d5 (0/2/0/0.21.2.239.0.0.5)
/dev/dsk/c6t0d5 (0/5/0/0.20.0.239.0.0.5)
/dev/dsk/c7t0d5 (0/5/0/0.20.5.239.0.0.5)

It look's like this LUN exists no more on your EMC storage, or is no more presented with the same lun id (5) to your hp-ux box, or simply no more presented. So in this configuration you can't have vgdata1 imported by ignite since it relies on LUN 0 and LUN 5.

So I still do wonder if any modification has been done at EMC side. And since lun 5 exists no more from HP-UX side, may be we could imagine that others things have been done on others LUNs that could explains why vgdata2 is also not imported.

==> 1st thing to do is to check with Storage Management Team what happened to the LUNs involved in vgdata1 and vgdata2. In particular lun 5 for vgdata1. May be lun numbers have been modified. Maybe lun have been erased then recreated. May be ...

==> You should try to import vgdata2. But honestly I don't think it will work because of this message in the doc attached in your initial post "vgimport: Physical Volume "/dev/dsk/c10t0d3" contains no LVM information" :

# mkdir /dev/vgdata2
# mknod /dev/vgdata2/group c 64 0x090000 [ Note : minor number 0x090000 must be unique, check with "ll /dev/*/group" and choose appropriate value if 0x090000 is already used ]
# /usr/sbin/vgimport -v -m /etc/lvmconf/vgdata2.mapfile /dev/vgdata2 /dev/dsk/c6t0d3 /dev/dsk/c10t0d3 /dev/dsk/c11t0d3 /dev/dsk/c7t0d3 /dev/dsk/c6t0d4 /dev/dsk/c10t0d4 /dev/dsk/c11t0d4 /dev/dsk/c7t0d4

Note : if file /etc/lvmconf/vgdata2.mapfile doesn't exist, don't care about it a retry vgimport without -m /etc/lvmconf/vgdata2.mapfile

Check and tell us.

Unfortunatly I will be far from Internet until next Monday.

Eric