pvmove question

[Juan Luis Morcillo]

Hi!
Just a simple question...
I have a vg with 2 disk and alternate paths (c8t0d0, c8t0d1 and c15t0d0 c15t0d1).
I would like to reuse cXt0d0, and I have cXt0d2 available for that purpose... is just as simple as using pvmove from t0d0 to t0d2? Can I do it "online" or should I deactivate the vg, or reduce the alternate path... what happens with alternate links, what should I expect later on a vgdisplay?
Thank you in advance

Juan-Luis

[Michael Tully]

Hi,

yes 'pvmove' is the command you after. If you wish to move all logical volumes from /dev/dsk/cxt0d0 to cxt2d2 all you need to do is:

# pvmove /dev/dsk/cxt0d0 /dev/dsk/cxt0d2

This will work providing there are enough free extents in which to do so. you can do on the fly. One further warning, do not do this if it is part of MC/SG.
The volume group must be de-activated. The 'pvmove' man page provides some good information on this.

Regards
Michael

[Stefan Farrelly]

Yes, you can do a pvmove on the fly - online, without any downtime. However - ensure your patches are recent/uptodate first. We did this once on a machine without patch updates for 2 years and it hung the box and we lost the data we were pvmoving.

You need to add into your VG the new disk you want to pvmove to, then once youve done the pvmove all data is moved to the new disk, and you can then vgreduce your VG to remove the disk you moved from - once you do this obviously alternate links will be affected. You will need to vgreduce the disk you pvmoved from and its alternate link.
If you have 2 paths to the new disk add them both into the VG before or after the pvmove.

[Juan Luis Morcillo_1]

The vg is not part of an MC/SG cluster.
Should I first include the destination pv on the vg (vgextend) or not?
I want to do it with people working over the lvols... it is safe (I am not worried about performance degradation)?
Thanks again

Juan-Luis

[melvyn burnard]

Yes, you first have to add in the new device and its alternate link with vgextend, then do the pvmove, and then vgreduce the origional device and its alternate link.
Wod of advice here, ensure you have a GOOD backup of the data on this VG , just in case......

[Juan Luis Morcillo_1]

Thank you all!
It works fine and fast...
Just one more question... why shouldn't I use it on exclusive vgs of a MC/SG package if my original disk (the one I want to remove) is not the cluster lock?
I understand that the only special task should be reimport vg on the secondary node after moving disks, isn't it?

Thanks,
Juan-Luis

[melvyn burnard]

well you could, but the vg would have to be deactivated to do this, and that means your package application is down