[ops] LVM migration from one SAN storage to another New SAN Box
smooney at redhat.com
Wed Sep 15 14:12:02 UTC 2021
On Wed, 2021-09-15 at 13:52 +0000, Jeremy Stanley wrote:
> On 2021-09-15 16:47:53 +0530 (+0530), KK CHN wrote:
> > I want to migrate our old SAN storage backend which contains LVMs
> > used for the cloud storage, to a New SAN Storage box.
> > The requirement was to migrate all storage of the old SAN box,
> > which was mounted to the controller node as /dev/sdb and /dev/sdc
> > around total 6TB storage. 80 % full. Then AMC of this box getting
> > over.
> > So what all are the steps to perform the migration of the old
> > storage to new SAN storage. Any hints most welcome
> While I've never tried this on an OpenStack compute node
> specifically, transparent relocation of logical volumes from one
> physical volume to another is a very longstanding feature of the
> LVM2 implementation in the Linux kernel, and I've used it many times
> on general purpose servers to replace the backend block devices in
> all sorts of situations.
i have done this by hand on my home system moving volume from local disk to
a disk shlef.
the approch i did was to expand the volume group and add the destiantion as a second PV to the VG
then i belive i had lvm move the data betwen the too for each volume then remove the orgin PV form the VG.
> The short answer is that you connect and add the new physical
> volumes to the same volume group which contains your existing
> logical volumes, then pvmove the extents for those LVs from the old
> PV to the new one, then you can remove the old PVs from the VG and
> disconnect them from the server. There is no need to take the
> volumes out of production for this, it can be done live while
> they're actively in use. The main caveat is that pvmove will put
> additional strain on your I/O channels moving data from one disk to
> another, possibly slowing your overall disk performance while it
yep this is what i did.
although since it was just a home cloud i fully stopped the vm
while i was doing it.
> I'll leave it to folks who manage OpenStack deployments to say
> whether this is a terrible idea, but this simple solution has served
> me well over the decades.
ya not sure how bad an idea it is the main concern would like be the createion of new
vms/volume while you are doing this.
if you can block that it woudl certenly help.
More information about the openstack-discuss