Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Move VG
- Thread starter MMacun
- Start date
RodKnowlton
MIS
- Apr 26, 2000
- 1,005
to be more specific:
if volumegroup named "thevg" and lives on a single LUN "hdiska" and the new LUN is "hdiskb" and of equal or greater size than hdiska, then:
extendvg thevg hdiskb
migratepv hdiska hdiskb
reducevg thevg hdiska
You won't even have to unmount the filesystems unless you want to kick the users off to reduce contention. migratepv basically mirrors one physical partition at a time, synchs them in case the original changed during the mirroring, then drops the original from the mirror.
Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
if volumegroup named "thevg" and lives on a single LUN "hdiska" and the new LUN is "hdiskb" and of equal or greater size than hdiska, then:
extendvg thevg hdiskb
migratepv hdiska hdiskb
reducevg thevg hdiska
You won't even have to unmount the filesystems unless you want to kick the users off to reduce contention. migratepv basically mirrors one physical partition at a time, synchs them in case the original changed during the mirroring, then drops the original from the mirror.
Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
- Thread starter
- #5
.
RodKnowlton
MIS
- Apr 26, 2000
- 1,005
Are you just wanting to remove a single LUN from the volume group and replace it with a LUN that's as big or bigger?
Then my initial instructions will work.
Otherwise, please post the output of the following commands for the volume group you're talking about:
lsvg vgname
lsvg -l vgname
lsvg -p vgname
and also describe the new LUN or LUNs, and what needs to be oved, and where.
Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
Then my initial instructions will work.
Otherwise, please post the output of the following commands for the volume group you're talking about:
lsvg vgname
lsvg -l vgname
lsvg -p vgname
and also describe the new LUN or LUNs, and what needs to be oved, and where.
Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
RodKnowlton
MIS
- Apr 26, 2000
- 1,005
Just reread your post.
migratepv will work fine, as long as the target LUN has enough room and nothing's mirrored.
You'll just need to execute it twice, once for each source disk.
Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
migratepv will work fine, as long as the target LUN has enough room and nothing's mirrored.
You'll just need to execute it twice, once for each source disk.
Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
- Thread starter
- #9
What "flashcopy" are you referrring to? ESS/DS flashcopy just makes identical copies of LUNs, and it is basically not a good idea to keep these disks unchanged on the same system after flashcopying.
If the source and target LUNs are known on the same server, you need to use recreatevg to change the PVIDs and VGIDs on the target LUNs and use the LUNs as a new VG with new FS names.
There are some good redbooks on this topic - see
Note that you can flashcopy a single LUN, but you need to flashcopy a complete set of LUNs containing a VolumeGroup - granted could be just one LUN: a VG with just one PV - if you want to get at the copied data after the flashcopy.
HTH,
p5wizard
If the source and target LUNs are known on the same server, you need to use recreatevg to change the PVIDs and VGIDs on the target LUNs and use the LUNs as a new VG with new FS names.
There are some good redbooks on this topic - see
Note that you can flashcopy a single LUN, but you need to flashcopy a complete set of LUNs containing a VolumeGroup - granted could be just one LUN: a VG with just one PV - if you want to get at the copied data after the flashcopy.
HTH,
p5wizard
- Thread starter
- #11
assign new luns on ESS to the server with the VG
run cfgmgr
run lsess (or lssdd if using SDD)
extendvg with new hdisks (or vpaths if SDD -> best to use smit if vpaths - extendvg4vp)
run migratepv oldpv newpv (run it once for every pair of PVs)
reducevg to remove old PVs from vg
rmdev -dl XXXX (vpaths and) hdisks - use info from lsess/lssdd
use the old PVs on the same server for a different VG
- or -
unassign old LUNs on ESS and they will be free for use ba another server.
Excuse my asking, but what is the point of this? except maybe the new LUNs are bigger. But if that is the case, why not just extendvg with additional LUNs. Or are you moving data from one ESS to another?
HTH,
p5wizard
run cfgmgr
run lsess (or lssdd if using SDD)
extendvg with new hdisks (or vpaths if SDD -> best to use smit if vpaths - extendvg4vp)
run migratepv oldpv newpv (run it once for every pair of PVs)
reducevg to remove old PVs from vg
rmdev -dl XXXX (vpaths and) hdisks - use info from lsess/lssdd
use the old PVs on the same server for a different VG
- or -
unassign old LUNs on ESS and they will be free for use ba another server.
Excuse my asking, but what is the point of this? except maybe the new LUNs are bigger. But if that is the case, why not just extendvg with additional LUNs. Or are you moving data from one ESS to another?
HTH,
p5wizard
- Thread starter
- #13
- Thread starter
- #14
- Thread starter
- #15
If I understand correctly, you have a VG with 2 disks (LUNs) and want to create a copy of the VG (lets say to do a trial run of the DB reorg.)
Stop the DB, flashcopy each of the 2 LUNs to their respective FC destination LUN. Then you have an exact copy of the VG on the dest. LUNs. For this reason it is best NOT to assign the destination LUNs to the same servers.
If you do, then a recreatevg will be necessary to modify the copied VG and its LVs/FSs - e.g. you can specify prefixes so that all the dest. LV names and labels (mount points in importvg stage) are modified:
lvora1:/oracle/data1 ==> duplvora1:/dup/oracle/data1
lvora2:/oracle/data2 ==> duplvora2:/dup/oracle/data2
and so on.
The command recreatevg is in fact a modified version of importvg, that will avoid having duplicate LV names, FS mount points, VGIDs and PVIDs, which is basically not a good idea.
Again, see the redbooks on this. I don't know the complete procedure(s) by heart.
HTH,
p5wizard
Stop the DB, flashcopy each of the 2 LUNs to their respective FC destination LUN. Then you have an exact copy of the VG on the dest. LUNs. For this reason it is best NOT to assign the destination LUNs to the same servers.
If you do, then a recreatevg will be necessary to modify the copied VG and its LVs/FSs - e.g. you can specify prefixes so that all the dest. LV names and labels (mount points in importvg stage) are modified:
lvora1:/oracle/data1 ==> duplvora1:/dup/oracle/data1
lvora2:/oracle/data2 ==> duplvora2:/dup/oracle/data2
and so on.
The command recreatevg is in fact a modified version of importvg, that will avoid having duplicate LV names, FS mount points, VGIDs and PVIDs, which is basically not a good idea.
Again, see the redbooks on this. I don't know the complete procedure(s) by heart.
HTH,
p5wizard
- Status