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 strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
combine multiple VGs
- Thread starter ekbb
- Start date
hi,
strictly answering no: you cannot pool a set of VGs in a
super VG: you can add PV to a VG.
what you can do is to move, copy, (in many ways) data from
VGx to VGy: copying files, bac/rest, using LV commands (as ogniemi suggested).
Could you explain your scope and give an idea of size of disks, fs, free spcaces,... ? is rootvg involved ?
bye
vic
strictly answering no: you cannot pool a set of VGs in a
super VG: you can add PV to a VG.
what you can do is to move, copy, (in many ways) data from
VGx to VGy: copying files, bac/rest, using LV commands (as ogniemi suggested).
Could you explain your scope and give an idea of size of disks, fs, free spcaces,... ? is rootvg involved ?
bye
vic
Code:
To move the contents of an LV to another VG I would usually do this:
create new LV in target volume group, and mount ata a temporary location ( eg /mnt ).
Stop the application that uses the LV
cd <root directory of source filesystem>
tar -cvf - * | ( cd /mnt ; tar -xvf - )
umount both directories
delete the original filesystem and logical volume.
Change the mount point for the new filesystem
mount the new filesystem
start the application.
Code:
umount /filesystem-I-want-to-move
cplv -Y new-lvname-prefix -v destination-vg source-lv
edit /etc/filesystems entry to the new lvname and change the jfs2log to the log of the new VG.
mount the moved file system
(rmlv oldlv if necessary)Regards,
Khalid
- Thread starter
- #6
Thsnks for the replies. I want to move data from an older disk system to a newer one; both of which are behind an SVC. The current LUNS are 35 GB and some of the VGs contain as many as 21 LUNS while others contain only one. I can not take an extended down to copy files, so I will add larger LUNS (140 GB) on the newer disk system to the VG and use migratepv for the large VGS. Then I will remove the LUNS on the old disk system from the VG. This will be a non-disruptive way to reduce the number of LUNS but not the number of VGs. I will migrate the smaller VGs to 35 GB LUNS on the new disk.
hi,
seen the scope, I'ld use files oriented program to copy
data, rather LV ones. I'ld use the following steps:
1) Make visible LUNs (PV) and make new VG.
2) umount one/all fs on old VG, chg mount point and remount
3) make new fs on new VG (in this phase, you can also change dimension (shrink or enlarge them)
and type jfs->jfs2, with the right mount point.
Suppose your fs has as mount point /home/fs01
mount old on /home/fs01old and ne sa /home/fs01
cd /home/fs01old
find . | cpio -pdm /home/fs01
this will copy all files and dir keeping structure and permissions
if you use cplv command, you must be skilled to manage
mount point in /etc/filesystem and Jfslog device, which has to point to that in new VG.
Probably this is faster, but my method is easier, and if
you have not experience with LV and logform is more secure.
bye
vic
seen the scope, I'ld use files oriented program to copy
data, rather LV ones. I'ld use the following steps:
1) Make visible LUNs (PV) and make new VG.
2) umount one/all fs on old VG, chg mount point and remount
3) make new fs on new VG (in this phase, you can also change dimension (shrink or enlarge them)
and type jfs->jfs2, with the right mount point.
Suppose your fs has as mount point /home/fs01
mount old on /home/fs01old and ne sa /home/fs01
cd /home/fs01old
find . | cpio -pdm /home/fs01
this will copy all files and dir keeping structure and permissions
if you use cplv command, you must be skilled to manage
mount point in /etc/filesystem and Jfslog device, which has to point to that in new VG.
Probably this is faster, but my method is easier, and if
you have not experience with LV and logform is more secure.
bye
vic
Moving a JFS/JFS2 File System to a New Volume Group:
- Thread starter
- #9
hi,
I don't know how is done your architecture, if there are DB
or how files are organized, how many LVs, ... how big.
If you prefere use LV command, I suggest to create a test LV
on old disks (oldVG) of simlar production dimension, and do the cplv and then verfy what you have to change to see new LV under the old fs name. Take the time of operation (it will be very useful to plane the migration), and
to verify file copy is much longer, perform also the test using find|cpio.
Any method you'll use, during migration data must be not accessed.
bye
vic
I don't know how is done your architecture, if there are DB
or how files are organized, how many LVs, ... how big.
If you prefere use LV command, I suggest to create a test LV
on old disks (oldVG) of simlar production dimension, and do the cplv and then verfy what you have to change to see new LV under the old fs name. Take the time of operation (it will be very useful to plane the migration), and
to verify file copy is much longer, perform also the test using find|cpio.
Any method you'll use, during migration data must be not accessed.
bye
vic
- Thread starter
- #11
To my understanding, the Logical Volume Manager commands (migratepv and migratelp)create a mirror of the source and are able to move data non-disruptively. While I will not achieve my objectives completely with migratepv, I will reduce my LUNs from 82 to 34.
If I wanted to take the time to script the transfer, migratelp would do it all.
If I wanted to take the time to script the transfer, migratelp would do it all.
- Status
Similar threads
