LVM raw devices migration to VxVM , HP-UX 11v23 , SG 11.18 and Oracle 11gR1

[jose da silva]

Hello

The current enviroment has RAW LVM data volumes. New Blade systems with HP-UX 11v31 are being deployd to replace the current HP-UX servers running HP-UX 11v23.What would be the best practice and steps for this migration considering the current RAW file systems.
The other question should I do the following:-
1. vgexport -p .... to create the map files and then vgimport to the new systems.
2. Then execute vxvmconvert etc.....

Please advise best practices on how I can approach this taking into consideration minimum downtime.

Regards
Jose

[Danny Petterson - DK]

Hi!

Hm....maybe Chapter 2 in this document can be of some help:

http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c02002479/c02002479.pdf

/Danny

[jose da silva]

Hello Danny

Thanks for your reply. I have been reading the document and I have found something very important :-
Note: This release only supports the conversion of LVM version 1 volume groups
to VxVM. It does not support the conversion of LVM version 2 volume groups. This must be noted.

Thanks
Jose

[Doug O'Leary · Accepted solution]

Hey;

I'm assuming you've already made the decision to move to vxvm instead of hp lvm. That's certainly not an invalid choice as vxvm is a technologically superior product - it does cost more, though... A lot more.

If the decision hasn't already been made, then make sure you understand the benefits that vxvm can give you and make an informed decision on whether or not those benefits are worth the cost.

My preferred method of converting between logical volume managers is to copy the data. Since these are oracle raw volumes, the only thing you need to do is create a vxvm volume of the same size and run dd:

dd if=${hp_lvm_raw} of=${vxvm_raw_vol} bs=10240

The internal format for the oracle files is no different be it HP LVM, vxvm, or even cooked files. In fact, that's how you convert between raw and cooked - dd...

The method above assumes you have extra disk space. If you can't completely replace the disk space, see if you can do it a few volumes at a time.

If that's not possible, you will probably have to open a service call with Symantec to see if they have any updates to the vxconvert script. Unless they changed that significantly, though, that really doesn't do anything except encapsulate the HP LVM structures - not the best option unless you can migrate that to different volumes.

Hope that helps.

Doug

[chris huys_4]

Hi Jose,

I did the vxvmconvert for a customer on HP-UX 11.11.

1. "pre-vxvmconvert" checks.

1.a checking if "full vxvm" software was installed
commands : swlist ; vxdctl license

1.b checking if asl is installed
check : hardware compatibility list of the support.symantec.com
command : vxdisk -o alldgs list;vxdisk list ; vxdmpadm listctlr all

comment : dont forget to check jbod requirements, sometimes they also need "attention"

1.c latest vxvm patching installed
check : latest vxvm patchset installed on itrc patch site

1.d get a sense of the typical volumegroup/logical volumes to be converted.
f.e.
command : vgdisplay -v /dev/vgXX

comment : 120 Gbyte volumegroup, PE size 32 Mbyte, 32 Gbyte luns

command : lvdisplay -v /dev/vgXX/YY

comment : logical volume of 1Gbyte in size; striped over 4 (EMC) luns; 64kbyte stripesize


1.e lvm volumegroup(s) containing mirrors using mwc

comment : think there is/was a problem with that on HP-UX 11.11

1.f lvm volumegroup(s) containing /usr filesystem

comment : not sure what the deal was with /usr..

1.g lvm volumegroup(s) with any dump or primary swap

comment : not sure what the deal was with dump/primary swap

1.h lvm volumegroup(s) used in MC/SG clusters

comment : MC/SG volumegroups need special care.. in essence they need to return to "normal" volumegroups for the duration of the vxvmconvert

1.i lvm volumgroup(s) used for cluster lock disks

comment : You dont convert MC/SG cluster lock volumegroups as there is no vxvm-equivalent of a cluster lock diskgroup, so they should stay lvm (and MC/SG clusters that have all data on vxvm diskgroups, work fine with LVM clusterlock volumegroups ; best of both worlds so to say)

1.j lvm volumegroup(s) with any disks that have bad block directory

command : bbdir

comment : bbdir is a hp support utility, can be asked for. checks the bad block directory. bad block directory should be empty before the conversion starts.

1.k Not enough space on the rootfilesystem to save a copy of each physical diskâ s LVM metadata

comment : vxvmconvert saves prior to the conversion, lvm metadata of the â to be converted volumegroupâ in the directory /etc/vx/reconfig.d/vgrecords/ of the rootfilesystem. The amount of data saved, depends on the size of the volumegroup, the luns in the LVM volumegroup etc .. . A check after each successfull LVM-VxVM volumegroup conversion, should be done, to check, if the amount of diskspace in the rootfilesystem, remains greater then +100Mbyte.If this isnâ t case, its recommended to copy the of earlier successful LVM-VxVM conversions, from the rootfilesystem to f.e. /home

1.l lvm volumegroup(s) with mirrored volumes need mirror license installed

comment : obvious is obvious. you need full vxvm with mirrored lvm volumes

1.m lvm volumegroup(s) with insufficient space for metadata

comment : the size of the lvm header determines the size of the vxvm header, and the size of the vxvm header determines how many "vxvm objects" can be stored in the vxvm header.. In my case the PE size of the volumegroup was 32 Mbyte. SO that means a lvm header of 32Mbyte at least. A 32 Mbyte vxvm header can contain a lot of vxvm objects so I had no problem there.. A PE size of 4Mbyte could give a problem when a lot of small lvm volumes needs to be converted, which will give a lot of vxvm objects. vxvm objects are volumes/plexes/subdisks. There is away to know the number of vxvm objects in a vxvm diskgroup. Think its vxdg list or something that lists it. There should also be a article about checking vxvm objects on symantecs site. Do some test vxvmconversions to get a feeling if you will have enough space.

1.n lvm logical volume(s) with 0 size

comment : there was a bug in vxvm 3.5 on hp-ux 11.11 that gave problems with vxvmconvert on "0 size" logical volumes. removing this volumes, before beginnning the conversion dealt with the problem.

1.o lvm volumegroup(s) containing the root volume

comment : not sure what was the problem with this.

2. conversion

2.a VRTSexplorer
comment : get VRTSexplorer data from each system before the conversion starts (script can be found on the symantec support site)

2.b. full backup of the userdata

2.c. backup of the LVM data

command : vgcfgbackup of each of the to be converted LVM volumegroups

2.d Stopping application access to implicated logical volumes / start volumegroups in â standardâ mode

The "standard" mode, is for the MC/SG volumegroups who needs to first loose there "exclusive" access settings to be able to converted.. (later they will get the good vxvm settings.. )

something like.

#

stop the implicated volumegroup
# vgchange â a n /dev/<>

remove the cluster flag from the implicated volumegroup
# vgchange â c n /dev/<>

start the volumegroups as â normalâ volumegroups
# vgchange â a y /dev/vg<>

# vgdisplay â v /dev/vg<>
VG status available

2.e. check if bbdir doesnâ t show any â not-emptyâ bad block directory
#cd /dev/rdsk

# for j in $(ls)
do
echo /var/tmp/bbdir.11 -d /dev/rdsk/$j
/var/tmp/bbdir.11 -d /dev/rdsk/$j |grep -i "bad block"
done

2.f. vxvmconvert
the vxvmconvert operation itself

2.g. implement changes for the new vxvm volume names
adapting /etc/lvmtab , adapting cntl scripts in MC/SG

2.h. Start the applications

You see quite a list. And while I did the above, actually a (vxvmconvert) bug was stumbled upon and as Im a HP support guy, who was doing some consulting on the side, the bug was worked around and later solved in a patch. (so that bug you shouldnt encounter anymore ;) )

The main time consumer is the amount of luns that are part of the volumegroups. The more luns in total all volumegroups "have" the longer the time to convert. I dont remember how much luns we had at the time, but I think for the above around 8 or 9 volumegroups needed to be converted which had a lot of luns, dont remember how much. I think in total we needed on average 30 minutes per volumegroup conversion or something like that.. (for the volumegroups with a lot of luns) We needed maybe 4 hours for all the volumegroups. Not sure how much TB that was "converted" that way, but it probably was a lot..

Good Luck,

Greetz,
Chris
PS. Doug, a dd will not convert a lvm header in a vxvm header, which is all that vxvmconvert does. The data is left alone, that is why vxvmconvert is so fast, it doesnt touch the data, as it doesnt need to touch that. After vxvmconvert is done, terabytes of data will be available on vxvm volumes instead of lvm volumes.

[jose da silva]

Hello Chris and Doug

Thanks for your thorough explanations which gave me a better insight what I need to do and take note.Why I asked these questions is that the customer is interested in Extended Clusters " running service guard- 2 nodes at DR and 2 nodes at Production sites which are +- 15 KM's away from each other" using DWDM and also for what I have read it states use VxVM. Please if you have any more inputs, suggestions and hints for this type of setup enviroment please can you forward it to me.

Thanking You
Jose