0

Hi, I am using a Linux distribution - Cent OS 6.10, if the OS version is not allowed here, please notify me and I'll delete this post, Thanks.

My logical volume seems to happen error as follows:

The logical volume size (VolGroup-lv_root) for the / directory is 50G initially.

I found its space is used up. So I add the /dev/vdc physical volume to the VolGroup volume group.

And then I tried to extend 100G to the VolGroup-lv_root logical volume but unintentionally used the command "lvextend -l +100%FREE -r VolGroup-lv_root" to extend all available volume group size to the LV.

I pressed "Ctrl+C" to stop the command after I found the command was wrong (the correct command should be lvextend -L +100G -r VolGroup-lv_root), and then the size of the LV stop to extend and the size shows 192G by the "df -h" commands:

df -h:

df -h

But I found the number(192G) is not the same as the size displayed in the "fdisk -l"(311.4GB), "pvs"(99.51GB), "lsblk"(290G) and lvs(289.99g) command.

fdisk -l: fisk -l

pvs & vgs:

pvs & vgs

lsblk: lsblk

lvs: lvs

We can find out that the total size of vda2 by pvs is 99.5 which is not equal to 290+10+39.5 by lsblk.

And I export the boot disk (dev/vda) and then transfer the exported file to a qcow2 file and then transfer the qcow2 file to a vmdk file and import the vmdk file to a VM and then export the VM to ovf files and then imported the ovf files into another VM(VM-new). However, the VM(VM-new) cannot work. Each user has his logical volume, so maybe this cause the accounts cannot log in:

Boot error messages: enter image description here

Is there something wrong after I pressed "Ctrl+C" before the command execution was finished and how to fix the size to make the disk can be migrated to a new VM successfully?

1
  • Welcome to Unix! Please replace the images of text with text. Text can be search and help with web search being directed to this question. Dec 22, 2022 at 1:14

1 Answer 1

0

Apparently when you pressed Ctrl-C, the LV expansion step was already completed and the expansion of the filesystem inside the LV was interrupted in the middle. The exact results of that would depend on the filesystem type used, but for example on ext4 filesystems, the on-line extension happens in steps, so if the extension command is interrupted, the result will be an intact filesystem that just isn't extended quite as far as intended.

Since you originally had lv_root at 50G and wanted to extend it by +100G, if the filesystem type allows shrinking, you might be able to fix this simply by:

lvreduce -L 150G -r VolGroup-lv_root

According to the output of pvs, there is a total of three disks in the VolGroup volume group. That means, any part of your LVs could be anywhere in these three PVs. You could use lvdisplay -m VolGroup-lv_root to see where each part of your root LV is, and if you had some free extents, you could use pvmove to move those parts of LVs around.

If you want to clone the vda disk only to a new VM, you would first have to ensure that all the LVs you want to be cloned are fully contained within that disk (i.e. no parts of those LVs are on vdb1 or vdc), and pvmove things around if that wasn't true. That would allow the root filesystem to be successfully activated on the new VM at least, although you will still get some errors about those LVs that were on vdb1 and vdc on the original system now being missing on the new VM. These would most likely cause the new clone to drop into single user mode on first boot.

To clean up those errors, you would have to use lvremove (possibly with -ff) to delete the missing LVs, and then use vgreduce --removemissing VolGroup to make LVM "forget" the missing PVs. You would also have to delete any references to the missing LVs from /etc/fstab.

After that, I would urge you to do a pvchange -u to the cloned PV on the new VM, and also vgchange -u VolGroup on the new VM, to ensure that the new clone has unique LVM UUIDs. This is not strictly required if you can guarantee that the cloned VG (or a snapshot of it) will never be presented back to the original system, but I find it safer to not leave traps like that behind me.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .