Replaced server - how to fix VGs

[Ken Englander]

I have swapped out a server completely and need to recreate the VGs. All the cables were disconnected from the existing server and plugged into the replacement with the same cards in the same slots.

I have a make_net_recovery backup but I'm having trouble communicating with the Ignite server.

I also have a mirror copy of vgo00 from the replaced server. I am trying to use this mirror to restore functionality. The disks now have different names. The issue I'm having relates to SAN devices.

I tried using map files saved by make_net_recovery but that does not work correctly.

So, I'm wondering what thoughts all of you might have on the easiest way to restore the connections to the disks.

If I can get Ignite to work is it smarter than using vgimport? Will it associate the right devices with the appropriate VGs.

The system is running HP-UX 11i v3, Mar09 update so everything is pretty current.

[Bill Hassell · Accepted solution]

vgimport will work OK but ignore the device file names -- they aren't useful at this point. You need to use the correct mapfile for vgimport and use the -vs options. This assumes that your mapfiles have the VGID number at the top of the file. vgimport will scan all the available disks and import all LUNs that match that VGID.

[Nido]

Hi Ken,

Are your both systems running HP-UX 11i v3?

HP-UX 11i v3 has persistent Device File, check if you're using persistent Device File in your old VGs.

Also, take a look on vgexport/vgimport man page which says to use `-s` option as Bill pointed out. You may take a look on examples as well on the man page.

hth

[Steven E. Protter]

Shalom,

vgimport should be able to use the volume groups, though some degree of renaming may be required after the fact.

I assume you have a good reason for trying to do an Ignite recovery and suggest that if that is really needed, it will take care of the volume group issues as well.

I'd like to see the error message and the command syntax used when those map files failed to work.

SEP

[Ganesan R]

Hi Ken,

If you have mirror disk and the path got changed on the new server, boot into maintanace mode then export the root vg and reimport it. So that the new path for root VG will be recognised by the LVM.

For importing the SAN disk, either you should have taken the map file with -s(VGID) option or you should know the new device files to import it.

Hope this helps.

[Ken Englander]

Ganesan R - There is no problem with the mirror - it boots fine. The problem was with the other disks.

Nido - Yes "both" systems are v3 - it is the same system (i.e. vg00) just running on a new (replacement) box.

Steven - I thought using Ignite would be much easier than all the manual steps involved in re-importing the volumes. However it seems that Ignite probably would not have worked either. However, I might have ended up with a cleaner list of devices in ioscan.

All - I found the export/import using "-s" and a map file does not work. An example of the error is below. I was able to use vgimport with the map and the actual PV successfully. Based on the error I received, I wonder if it has something to do with the CPU ID.

Note, most of the disks are shared so I was able to obtain current maps but that did not help.

root@l13crn02:/> vgimport -v -N -s -m /tmp/mq02vg.map /dev/mq02vg
Beginning the import process on Volume Group "/dev/mq02vg".
vgimport: Physical volume "" could not be added to "/etc/lvmtab" and
therefore was not added to the volume group.
Logical volume "/dev/mq02vg/mq02loglv" has been successfully created
with lv number 1.
Logical volume "/dev/mq02vg/mq02datalv" has been successfully created
with lv number 2.
vgimport: Volume group "/dev/mq02vg" has been successfully created.
Warning: A backup of this volume group may not exist on this machine.
Please remember to take a backup using the vgcfgbackup command after activating the volume group.

RETRY with explicit PV specified

root@l13crn02:/> vgexport mq02vg
vgexport: Volume group "mq02vg" has been successfully removed.
root@l13crn02:/> ls /dev/mq*
group mq01datalv mq01loglv rmq01datalv rmq01loglv
root@l13crn02:/> mkdir /dev/mq02vg
root@l13crn02:/> mknod /dev/mq02vg/group c 64 0x040000
root@l13crn02:/> vgimport -v -m /tmp/mq02vg.map /dev/mq02vg /dev/disk/disk490
Beginning the import process on Volume Group "/dev/mq02vg".
vgimport: Warning: Volume Group belongs to different CPU ID.
Can not determine if Volume Group is in use on another system. Continuing.
Logical volume "/dev/mq02vg/mq02loglv" has been successfully created
with lv number 1.
Logical volume "/dev/mq02vg/mq02datalv" has been successfully created
with lv number 2.
vgimport: Volume group "/dev/mq02vg" has been successfully created.
Warning: A backup of this volume group may not exist on this machine.
Please remember to take a backup using the vgcfgbackup command after activating the volume group.

[Bill Hassell]

> All - I found the export/import using "-s" and a map file does not work. An example of the error is below.

I don't an error in either session. There is a warning (that is always given with vgimport) that a vgcfgbackup needs to be done. But the VG appears to be successfully create without an explicit PV list as well as with the PVs listed.

> I was able to use vgimport with the map and the actual PV successfully. Based on the error I received, I wonder if it has something to do with the CPU ID.

The CPUID is again a simple warning. It means that the PVs were originally created on a different CPU but does not prevent importing the VG to another CPU.

[Sharma Sanjeev]

Hi Ken

There is no issues with any of above

There is a CPU ID warning and that is because the VG's were create on diffrent node.

Regards
Sanjeev

[Ken Englander]

Unfortunately, now that I am done, I cannot try to verify if I had a working VG or not.

I considered the following message to be an error. It is certainly not a part of the typical messages I see when importing shared VGs.

vgimport: Physical volume "" could not be added to "/etc/lvmtab" and
therefore was not added to the volume group.

[Michael Steele_2]

Hi

More than likely this is an unsupported physical device. You should note its make and model and verify compatibility with HP. I don't see any info about the SAN devices, please post and I'll check for you.

Re: Can't communicate with ignite server.

This can be a few things. With the error message I could be more helpful. However, ignite versions should be checked. Here are most, NS = not supported. S = supported. Run "...swlist -l fileset | grep -i ignite..." to find both your server's and your client's versions and compare. They should be the same.

HP-U
OS B
Product Release Product Product 11. 11. 11.
Description Base Date Number Version 31 23 11
Ignite UX 11.31 Feb. 07 IGNITE C.7.0.212 S
Ignite UX 11.11 Jun. 07 IGNITE C.7.2.94 S S
Ignite UX 11.23 Jun. 07 IGNITE C.7.2.94 S S
Ignite UX 11.11 Sep. 07 IGNITE C.7.3.141 S S S
Ignite UX 11.23 Sep. 07 IGNITE C.7.3.144 S S S
Ignite UX 11.31 Sep. 07 IGNITE C.7.3.144 S S S
Ignite UX 11.11 Dec. 07 IGNITE C.7.4.155 S S S
Ignite UX 11.23 Dec. 07 IGNITE C.7.4.155 S S S
Ignite UX 11.31 Dec. 07 IGNITE C.7.4.155 S S S
Ignite UX 11.11 Mar. 08 IGNITE C.7.5.142 NS NS S
Ignite UX 11.23 Mar. 08 IGNITE C.7.5.142 NS S NS
Ignite UX 11.31 Mar. 08 IGNITE C.7.5.142 S NS NS
Ignite UX 11.23 Jun. 08 IGNITE C.7.6.98 S S S
Ignite UX 11.11 Sep. 08 IGNITE C.7.7.93 NS NS S
Ignite UX 11.23 Sep. 08 IGNITE C.7.7.93 NS S NS
Ignite UX 11.31 Sep. 08 IGNITE C.7.7.93 S NS NS
Ignite UX 11.11 Sep. 09 IGNITE C.7.8.201 NS NS S
Ignite UX 11.23 Sep. 09 IGNITE C.7.8.198 NS S NS
Ignite UX 11.31 Sep. 09 IGNITE C.7.8.201 S NS NS
Ignite-UX 11.11 Dec. 00 B5725AA B.3.0.502 S
Ignite-UX 11.11 Mar. 01 B5725AA B.3.2.45 S
Ignite-UX 11.11 Jun. 01 B5725AA B.3.3.116 S
Ignite-UX 11.11 Sep. 01 B5725AA B.3.4.115 S
Ignite-UX 11.11 Dec. 01 B5725AA B.3.5.89 S
Ignite-UX 11.11 Mar. 02 B5725AA B.3.6.82 S
Ignite-UX 11.11 Jun. 02 B5725AA B.3.7.95 S
Ignite-UX 11.11 Sep. 02 B5725AA B.3.8.186 S
Ignite-UX 11.11 Dec. 02 B5725AA B.4.1.55 S
Ignite-UX 11.11 Mar. 03 B5725AA B.4.2.110 S
Ignite-UX 11.23 May. 03 B5725AA B.5.0.35 S NS
Ignite-UX 11.11 Jun. 03 B5725AA B.4.3.91 S
Ignite-UX 11.11 Sep. 03 B5725AA B.4.4.29 S
Ignite-UX 11.11 Dec. 03 B5725AA B.5.1.33 S
Ignite-UX 11.11 Mar. 04 B5725AA B.5.2.124 S S
Ignite-UX 11.23 Mar. 04 B5725AA B.5.4.50 S NS
Ignite-UX 11.11 Jun. 04 B5725AA B.5.4.50 S S
Ignite-UX 11.23 Sep. 04 B5725AA C.6.0.109 S
Ignite-UX 11.11 Dec. 04 B5725AA C.6.1.44 S S
Ignite-UX 11.23 Dec. 04 B5725AA C.6.1.44 S S
Ignite-UX 11.11 May. 05 B5725AA C.6.2.241 S S
Ignite-UX 11.23 May. 05 B5725AA C.6.2.241 S S
Ignite-UX 11.11 Sep. 05 B5725AA C.6.3.324 S S
Ignite-UX 11.23 Sep. 05 B5725AA C.6.3.324 S S
Ignite-UX 11.11 Dec. 05 B5725AA C.6.5.61 S S
Ignite-UX 11.23 Dec. 05 B5725AA C.6.5.61 S S
Ignite-UX 11.11 Mar. 06 B5725AA C.6.7.79 S S
Ignite-UX 11.23 Mar. 06 B5725AA C.6.7.79 S S
Ignite-UX 11.11 Jun. 06 B5725AA C.6.8.150 S S
Ignite-UX 11.23 Jun. 06 B5725AA C.6.8.150 S S
Ignite-UX 11.11 Sep. 06 B5725AA C.6.9.141 NS S
Ignite-UX 11.23 Sep. 06 B5725AA C.6.9.141 S NS
Ignite-UX 11.11 Dec. 06 B5725AA C.6.10.97 S S
Ignite-UX 11.23 Dec. 06 B5725AA C.6.10.97 S S

KEY: Release Media: Identifies on which HP-UX Application Software CD set a
particular product/version was introduced
Base : HP-UX Operating System Release (i.e. 11.0, 11.10 etc.)
Date : The Release date on CD
HP-UX OS Base: S = Supported, you may install that product and
version on the indicated HP-UX Operation System
NS = Not Supported, and should not be installed on
the indicated HP-UX Operation System

[Ken Englander]

Michael,

Thanks for the input. The device is not unsupported - it is the same device that was in use before the hardware chasis was replaced.

As for the Ignite issue, it is unfortunately a PXE-E18 error, which I have found can be a bit elusive. I am open to ideas about what it might be. This occurs the first time the client is attempting to establish a tftp session with the server.