LVM migration from one SAN storage to another New SAN Box
List, 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 Kris
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. 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 runs. 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. -- Jeremy Stanley
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 runs.
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.
participants (3)
-
Jeremy Stanley
-
KK CHN
-
Sean Mooney