I'm fairly new to LVM, largely because I have avoided it for many years. I know basically what it is, but I've never needed the capability to resize volumes at will, or extend onto another physical drive.
So I'm writing this post for two reasons: 1) to confirm whether I got it right, and 2) to provide information to others struggling to understand LVM (and how Proxmox uses it.)
Let's put LVM aside and start with block devices.
Starting point, you have a working system with a single physical drive, which shows up at /dev/sda (ignoring partitions, etc, this is just so the next part can say "sdb.")
You buy a new, totally blank drive, install it, and boot up. This drive shows up as /dev/sdb. There is not yet any sdb1, sdb2, etc.
It's a block device. It has no file system (yet.) But you can still read or write it, for instance with dd. (Even though there's initially no real data to "read.")
Now run fdisk, cfdisk, whatever, choose GPT or MSDOS, and add one partition of some type. After this, the new partition will show up at /dev/sdb1.
sdb1 is still a "block device" but kind of virtualized. It's a specific range of the disk, which the partition table knows about. So you could still read/write it "raw" with dd, but the system would use the partition table to limit access to the blocks allocated to the partition.
Now format sdb1 with some file system type. NOW you can mount it, and write files and directories to it.
So on to LVM.
"Physical Volume"
The term "Physical Volume" may be a bit misleading. It doesn't mean "raw physical disk." It means, either an entire "raw physical disk," or a partition on that disk, that has been "created" to use with LVM.
For instance, starting with /dev/sdb totally unformatted (no partition table,)
pvcreate /dev/sdb
sets up /dev/sdb as an LVM "Physical Volume." Meaning, it's not totally blank anymore, some information has been written that allows LVM to "see" it. More or less equivalent to a partition table (not exactly the same, but similar in the sense of "information that tells the system what to do with these blocks.")
But you can also pvcreate a partition. So go back to a totally blank sdb, then fdisk it to have one partition, of type lvm. That would be /dev/sdb1.
pvcreate /dev/sdb1
Now you have a physical volume on a partition. If your partition doesn't fill the entire disk, you can create other non-LVM partitions. (like Proxmox install does for the boot disk.)
So an LVM "Physical Volume" is still somewhat "virtual." It's just "flagging" an entire disk, or partition, as a block device LVM can use. But it's not quite equivalent to a regular drive or partition, yet. That's a "Volume Group."
"Volume Group"
A volume group is equivalent to a raw physical drive. Or maybe, a raw physical drive with a partition table. Jumping ahead a bit, a "Logical Volume" is equivalent to a regular partition, so why the middle layer? So that a volume group can span multiple physical volumes, which may be on different "raw physical drives," or multiple physical volumes on one "raw physical drive." (See why I think "Physical Volume" may be a bit misleading?)
"Logical Volume"
Finally, this is equivalent to a regular partition. You can format it to whatever file system type you want, mount it, and access the file system.
How Proxmox uses LVM
You create your "Physical Volume(s)" and "Volume Group(s)" but no "Logical Volume(s)".
You add storage as type LVM, and choose the volume group.
Initially, lvdisplay shows no Logical Volumes on this Volume Group.
When you create a VM or container, rather than creating a disk image file as it would on "Directory" storage, Proxmox actually creates a "Logical Volume" for the machine.
You can see these volumes with lvdisplay. For instance, for a container with id 100 and one disk, you should see volume "vm-100-disk-0".
And by the way, you can mount this to browse the filesystem, whether the machine is on or off. Which might even be a bit easier than mounting a disk image file on Directory storage, with a loop.
I believe this should be the same for LVM thin. Can anyone confirm?
Please correct me anywhere I am wrong.
So I'm writing this post for two reasons: 1) to confirm whether I got it right, and 2) to provide information to others struggling to understand LVM (and how Proxmox uses it.)
Let's put LVM aside and start with block devices.
Starting point, you have a working system with a single physical drive, which shows up at /dev/sda (ignoring partitions, etc, this is just so the next part can say "sdb.")
You buy a new, totally blank drive, install it, and boot up. This drive shows up as /dev/sdb. There is not yet any sdb1, sdb2, etc.
It's a block device. It has no file system (yet.) But you can still read or write it, for instance with dd. (Even though there's initially no real data to "read.")
Now run fdisk, cfdisk, whatever, choose GPT or MSDOS, and add one partition of some type. After this, the new partition will show up at /dev/sdb1.
sdb1 is still a "block device" but kind of virtualized. It's a specific range of the disk, which the partition table knows about. So you could still read/write it "raw" with dd, but the system would use the partition table to limit access to the blocks allocated to the partition.
Now format sdb1 with some file system type. NOW you can mount it, and write files and directories to it.
So on to LVM.
"Physical Volume"
The term "Physical Volume" may be a bit misleading. It doesn't mean "raw physical disk." It means, either an entire "raw physical disk," or a partition on that disk, that has been "created" to use with LVM.
For instance, starting with /dev/sdb totally unformatted (no partition table,)
pvcreate /dev/sdb
sets up /dev/sdb as an LVM "Physical Volume." Meaning, it's not totally blank anymore, some information has been written that allows LVM to "see" it. More or less equivalent to a partition table (not exactly the same, but similar in the sense of "information that tells the system what to do with these blocks.")
But you can also pvcreate a partition. So go back to a totally blank sdb, then fdisk it to have one partition, of type lvm. That would be /dev/sdb1.
pvcreate /dev/sdb1
Now you have a physical volume on a partition. If your partition doesn't fill the entire disk, you can create other non-LVM partitions. (like Proxmox install does for the boot disk.)
So an LVM "Physical Volume" is still somewhat "virtual." It's just "flagging" an entire disk, or partition, as a block device LVM can use. But it's not quite equivalent to a regular drive or partition, yet. That's a "Volume Group."
"Volume Group"
A volume group is equivalent to a raw physical drive. Or maybe, a raw physical drive with a partition table. Jumping ahead a bit, a "Logical Volume" is equivalent to a regular partition, so why the middle layer? So that a volume group can span multiple physical volumes, which may be on different "raw physical drives," or multiple physical volumes on one "raw physical drive." (See why I think "Physical Volume" may be a bit misleading?)
"Logical Volume"
Finally, this is equivalent to a regular partition. You can format it to whatever file system type you want, mount it, and access the file system.
How Proxmox uses LVM
You create your "Physical Volume(s)" and "Volume Group(s)" but no "Logical Volume(s)".
You add storage as type LVM, and choose the volume group.
Initially, lvdisplay shows no Logical Volumes on this Volume Group.
When you create a VM or container, rather than creating a disk image file as it would on "Directory" storage, Proxmox actually creates a "Logical Volume" for the machine.
You can see these volumes with lvdisplay. For instance, for a container with id 100 and one disk, you should see volume "vm-100-disk-0".
And by the way, you can mount this to browse the filesystem, whether the machine is on or off. Which might even be a bit easier than mounting a disk image file on Directory storage, with a loop.
I believe this should be the same for LVM thin. Can anyone confirm?
Please correct me anywhere I am wrong.