This concerns a CentOS7 server using LVM and hosted as a VM on Hyper-V. As far as I understand the history, it is like this:

The VM was establish with a fixed virtual drive 1.75 years ago. That virtual fixed disk ran out of space 8 months ago. A second, dynamic virtual drive was created. Now the Hyper-V host is running out of disk space entirely and some fundamental decisions need to be made.

However, I am confused by LVM picture -- it appears the second disk was added to the VG but not to a LV. I did not realize that was possible and I am not sure I understand the implications of that. Here are some screen shots:

First, on this lsblk, I am confused as to how the centos home size is larger than the partition it is under. What does that imply?

lsblk command results

Then, on this series of pvs, vgs, and lvs commands it seems that the sdb PV was not added to any of the LVs on the VG centos.

pvs, vgs and lvs command displays

Yet clearly they are storing data to sdb so I assume management of that storage is outside of the LVM construct. Is that correct? And given that the PV is in the VG, does this imply some sort of risk? Or, because it was never assigned to a LV, it is in the VG but not actually being managed at all by LVM.

I'd like to figure out the best way to get this cleaned up when the physical storage issues are sorted out. It seems like what needs to happen is that all the PV in the VG need to be assigned to an LV and in this case it seems the home LV is the logical place. It is possible to make that reassignment now? Is it only possible with the free space on the sdb or will it reassign the the entire PV and is that safe? Or is the way to handle this is move all the existing PV to a new third disk sdc and then recreate the entire VG / LV breakdown.

Any suggestions on how to proceed are appreciated. Thank you.

--- Update ---

I am slowly wrapping my mind around this - thanks for the comments. In the below image, am I correct to interpret this to mean that though a total of ~5.86t in PV was allocated to the VG the size of the LV at 2.9t means only about half of that is actually available to the LV? Is there some mechanism whereby an LV grows dynamically?? If not, then I would have to use the lvextend command (and extend file system as well) to increase the PV allocation to the LV?

enter image description here

2 Answers 2


The second disk is being used through LVM: /dev/sdb1 is part of the home LV. That’s why that LV is larger than its containing partition in the lsblk output.

To see how your PVs are used by your LVS, run

lvs -o +devices
  • Thank you - I am reading through the help pages of these commands now to better understand how to find the right information -- here is the output from the above command as pertains to sbd1: home centos -wi-ao---- <2.90t /dev/sdb1(0) ... I am going to read through redhat docs to figure out exactly what this is saying. Thanks again.
    – nxm
    Sep 12, 2023 at 5:50

LVM structures Logical Volumes (LV) on top of Volume Groups (VG). These Volume Groups are composed of one or more Physical Volumes (PV).

Logical volumes look like contiguous partitions, but they aren't necessarily mapped to contiguous regions on a single drive like traditional partitions. The chunks that actually store the data (called extents) can be found over potentially multiple physical volumes.

First, on this lsblk, I am confused as to how the centos home size is larger than the partition it is under. What does that imply?

This home logical volume is on top of both of the PVs, rather than being contained fully on just one of them, this means you can make a bigger volume than the size of either physical volumes, but be careful, since this also means the loss of either can mean the loss of your data.

It seems like what needs to happen is that all the PV in the VG need to be assigned to an LV

It's sort of the other way around, the PVs in a VG contain all of the extents. The LVs are then configured as a mapping into those extents on those PVs, so it's more like the LVs are assigned to PVs.

You currently have ~2.91TB available that's unused in the volume group. What you do with that is up to you, e.g. you could:

  1. mirror some data for resiliency in case one of your drives fail;
  2. add more logical volumes;
  3. extend some existing multiple volumes to give more space to the underlying filesystem/swap space; etc...
  • Thank you - me having the logic of LV assigned to PV backwards was definitely a stumbling block in my understanding what I was seeing. When you say ~2.91TB is "unused" is that the same as saying the home LV is not allocated those extents?
    – nxm
    Sep 12, 2023 at 5:45
  • 1
    In the pvs output, "unused" means extents that have not been allocated to any LV. They are free to be used for creating new LVs and/or extending existing ones, however you want. But the extension is not automatic, mostly because extending a filesystem is usually easier than shrinking it. Some filesystem types (e.g. XFS) cannot be shrunk non-destructively at all.
    – telcoM
    Sep 12, 2023 at 6:36
  • Thank you - this is starting to make better sense.
    – nxm
    Sep 12, 2023 at 6:46

You must log in to answer this question.

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