moving vg from external drives to autoraid 12h

[anthony natale]

OK, some system specs:
OS: HPUX 10.2
VG name: vg07
LVs: 4
Basically I want to move vg07 from its existing location(old external drive drawers), and put vg07 on our 12h Autoraid. I've been simulating VG moves between PVs and having some doubts as to the correct order to do things. I just wanted one of my simulations to run correctly the first time (don't we all?)
So if it isn't too much trouble, and hopefully I have given enough info, could someone please let me know the best way to accomplish this seemingly simple task.
Thanks

anthony.

[Sandip Ghosh]

Add the LUN in the existing vg07.
And the do pvmove.
Otherwise you cna do mirror and take out the old drive from the mirror.

Sandip

[A. Clay Stephenson]

The first thing to do is add the 12H LUN(s). My suggestion is that you create 2 equally sized LUN's for this VG. Primary path should be through controller X on (alternate Y) for the first LUN and the reverse of this for the second LUN. This will fully utilize both external paths. When you create each of your LVOL's, stripe across both LUNS in 64K chunks.

Even if you have MirrorDisk/UX, I rather doubt that you will be able to do a vgextend because the size of the new LUN's will probably exceed the size of your largest current physical disk. It's probably not a good idea to cheat by using AutoRAID LUN's no larger than your current disks because you will rapidly use up your 8 LUN's. Your best bet will probably be to do this the old-fashioned way and make the new VG and copy the data.

[S.K. Chan]

If you're talking pvmove, yes it is possible but the LUN-device-path that you've created has to be part of vg07 because you CAN'T pvmove across different VGs. One important condition, if your lvol is "stripe" you cannot do a pvmove. Check ..
# lvdisplay -v /dev/vg07/lvolX | more
==> look for "stripe" , has to be 0.
My opinion is pvmove is risky and you have to backup your data before performing a pvmove. Given that you might as well create a separate VG with the 12H LUN and copy the data across, like what Clay's recommending. Do you want to go that route ?

[anthony natale]

First of all let me just say that you guys are quick!

Thanks for all the responses. The vg in question is about 4GB in size only. But we are trying to get rid of these antiquated external drive drawers. I thought I could just do a vgexport and vgimport to get the vg config to see the new hardware path. I'm thinking now that I may have been looking at it the wrong way.

I thought about the mirroring route. I need to keep the same VG name due to oracle connections. It is being used as a test region. So I'm thinking maybe I should do a vgexport, get the old pv info out of the system, and then basically create the vg on the autoraid, recreate the lvols (there are 4), and restore the data. I thought I would be able to use vgimport to reestablish the lvols once I created the vg on the autoraid. I'd be interested to know if I'm on the right track here. Thanks again, you guys kick butt.

anthony.

[A. Clay Stephenson · Accepted solution]

Yes, you are are the right track. I would still suggest that you use 2 LUN's especially since this is a database. In your case, I would:
0) Backup
1) Create the new LUN's
2) create a new VG, e.g. vg08 and activate the new VG
3) create your 4 LVOL's on vg08 striping across both LUN's; if you need filesystems, create and mount them as temp directories.
4) If you are using raw/io, you will need to use dd to copy the data from the original to the new lvol. For regular files copy them probably with cpio -p.
5) Unmount the new filesystems; unmount the old filesystems.
6) vgchange -a n /dev/vg08
7) vgchange -a n /dev/vg07
8) vgexport -m /tmp/vg08.map /dev/vg08
9) mkdir /dev/vg07; mknod /dev/vg07/group c 64 0x07000 (this is probably the correct minor number)
10) vgimport -m /tmp/vg08.map /dev/vg07 LUN0XPath LUN0YPath LUN1YPath LUN1XPath

11) vgchange -a y /dev/vg07
12) If you have done your job correctly, the entries in /etc/fstab should still be correct; mount the /dev/vg07 filesystems
13) Check the ownerships/permissions of any raw device nodes.

This should be rather close.

By the way, I never use raw device nodes directly in Oracle. If you are going to use them, make your datafiles something like /xxx/data01.dbf. You then create a symbolic link from /xxx/data01.dbf to /dev/vg07/rlvol1. That way it is trivially easy to move database raw files.

[S.K. Chan]

Clay , can you verify .. shouldn't vg07 be exported as well ..

7) vgchange -a n /dev/vg07
==> 7i) vgexport /dev/vg07
8) vgexport -m /tmp/vg08.map /dev/vg08

thanks ..

[A. Clay Stephenson]

Yes, good catch.

I should also add that if you created temp entries in /etc/fstab, they should be removed. The temp mountpoints should be removed.