In your scenario, the vgexport
/vgimport
is not really necessary, precisely because you already know the existing VG names in the new machine.
For renaming a VG on the old system, you'll most likely need to unmount and deactivate it first, and since there is no VG name conflict there, you don't have to use the VG UUID instead of the old VG name (although you can if you wish):
umount /mount-point/
vgchange -an Old_VG_Name
vgrename Old_VG_Name New_VG_Name
vgchange -ay New_VG_Name
<edit /etc/fstab to replace Old_VG_Name with New_VG_Name>
mount /mount-point
Before removing the disks:
<edit /etc/fstab to comment out/remove the line for the /mount-point/>
umount /mount-point/
vgchange -an Old_VG_Name # technically the shutdown procedure would do this too
You could even hot-unplug the disks if you do this after deactivating the VG:
echo 1 > /sys/block/sdc/device/delete
echo 1 > /sys/block/sdd/device/delete
This tells the kernel to prepare for the imminent physical disconnection of those devices. (If you are using paravirtualized drivers in a VM, the virtualization host may send a warning message to the driver before hot-removal of a virtual disk, making this step unnecessary.)
Once the disks are moved to a new system, the normal system start-up procedure will in most distributions automatically execute the equivalents of pvscan
and vgchange -ay
, activating all non-conflicting VGs automatically by default. In that case, you'll only need to create a mount point directory, edit /etc/fstab
and mount the volume:
mkdir /olddata
<edit /etc/fstab>
mount /olddata
What is the purpose of vgexport
/vgimport
then, you might ask? It is for the situation when you don't know if there will be a VG with the same name in the new system or not. When a VG is exported, the VG metadata on the disk is marked effectively "skip me", and so the VG will avoid the automatic activation step at system start-up, and all the LVM management commands will prefer the existing non-exported VG on the new system over the possibly-conflictingly-named new arrival, until the system administrator gets around to renaming & importing it. vgimport
removes this mark. It does nothing else.
The above is true for Linux LVM version 2, which has existed since the beginning of the 2.6 kernel series. If you deal with 2.4.xx or older kernels, you might have LVM version 1, for which the vgexport
/vgimport
commands might have worked differently (I don't remember the details of those any more).
vgrename
while filesystem is mounted.