On a Linux server with two blank disks, explain LVM's three layers — physical volume, volume group and logical volume — and give the commands, in order, that turn those disks into a mounted filesystem.
answer
- three layers, bottom to top
- disk gets labelled, then pooled
- the pool is chopped into extents
- pvcreate, vgcreate, lvcreate, mkfs
- filesystem sits on /dev/vg/lv
basics
~20 sLVM stacks three layers: pvcreate initialises each disk as a physical volume, vgcreate pools those PVs into a volume group, and lvcreate carves logical volumes out of the pool. Then you mkfs and mount the LV like any block device.
solid answer
~40 sLVM inserts a virtualisation layer between disks and filesystems. A **physical volume** is a block device — a whole disk or a partition — that `pvcreate` has labelled for LVM use. A **volume group** is a pool built from one or more PVs; `vgcreate vg0 /dev/sdb /dev/sdc` merges both disks' capacity into one address space, chopped into fixed-size physical extents. A **logical volume** is a slice of that pool: `lvcreate -L 200G -n data vg0` hands you `/dev/vg0/data`, a normal block device that may be backed by extents from either disk. From there it is ordinary storage — `mkfs.ext4 /dev/vg0/data`, then mount it. The payoff is that the filesystem is no longer welded to one physical disk, so capacity can be added to the pool later without moving data.
code
bash · 7 linespvcreate /dev/sdb /dev/sdc
vgcreate vg0 /dev/sdb /dev/sdc
lvcreate -L 200G -n data vg0
mkfs.ext4 /dev/vg0/data
mkdir -p /srv/data
mount /dev/vg0/data /srv/data
lvs vg0go deeper
Be able to name the three layers in order and give the command for each: pvcreate, vgcreate, lvcreate, then mkfs and mount. Say plainly that the filesystem goes on the logical volume, not on the group.
Explain what pvcreate actually writes to the disk, that the VG is divided into fixed-size extents, and why an LV can be larger than any single member disk.
Show that you treat the VG as the capacity pool you manage: leaving headroom unallocated, knowing which PV backs which extents via lvdisplay -m, and reading pvs/vgs/lvs to orient yourself on a machine you have never seen.
Own the convention: whether hosts get one VG or several, how much of the pool stays unallocated as insurance, and when a workload should skip LVM entirely because its storage is already virtualised beneath you.
## Why the layer exists Without LVM, a filesystem lives on a partition, and a partition is a fixed range of sectors on one disk. If it fills up, your options are ugly: back up, repartition, restore. LVM breaks that binding by putting a pool in the middle. Disks feed the pool; filesystems are served out of the pool; the two no longer have to line up. ## Layer 1 — the physical volume (PV) A PV is any block device you have handed to LVM with `pvcreate`. It can be a whole disk (`/dev/sdb`), a partition (`/dev/sdb1`), a multipath device, or a RAID array exposed by a controller. `pvcreate` does not reformat the device. It writes a small LVM label (by default in the second 512-byte sector) plus a metadata area holding a text description of the volume group this PV belongs to. That is why LVM metadata is self-describing: plug the disks into another machine and the configuration comes with them. ## Layer 2 — the volume group (VG) `vgcreate vg0 /dev/sdb /dev/sdc` creates a named pool from those PVs. The VG's total capacity is the sum of its PVs, and it is divided into equal-sized **physical extents** (PEs) — 4 MiB each by default. The extent is LVM's unit of allocation: everything above this layer is bookkeeping about which extents belong to which logical volume. The VG is also the boundary of allocation. A logical volume can only take extents from PVs inside its own VG; it can never straddle two VGs. ## Layer 3 — the logical volume (LV) `lvcreate` allocates extents from the VG and presents them as a block device: ```bash lvcreate -L 200G -n data vg0 # by size lvcreate -l 100%FREE -n data vg0 # all remaining extents ``` The result appears as `/dev/vg0/data` (and `/dev/mapper/vg0-data`). Because the extents may come from more than one PV, a 200 GiB LV can exist on a VG made of two 150 GiB disks — something a partition could never do. By default the layout is *linear*: extents are taken from one PV until it is exhausted, then from the next. It is concatenation, not RAID; LVM by itself adds no redundancy. ## Putting a filesystem on it An LV is an ordinary block device, so the rest is unremarkable: ```bash pvcreate /dev/sdb /dev/sdc vgcreate vg0 /dev/sdb /dev/sdc lvcreate -L 200G -n data vg0 mkfs.ext4 /dev/vg0/data mkdir -p /srv/data mount /dev/vg0/data /srv/data ``` The filesystem has no idea LVM is underneath. It sees a device with a size, and reads and writes sectors; device-mapper translates each of those sectors to a location on a real disk. ## Checking your work Each layer has a reporting command, and they are the first thing to reach for on an unfamiliar machine: - `pvs` — one line per physical volume: which VG it belongs to, its size (`PSize`) and how much of it is unallocated (`PFree`). - `vgs` — one line per volume group: number of PVs and LVs, total size (`VSize`) and free space (`VFree`). - `lvs` — one line per logical volume: its VG, size (`LSize`) and an attribute string such as `-wi-ao----`, where the `a` means active and the `o` means currently open (mounted). The verbose forms `pvdisplay`, `vgdisplay` and `lvdisplay` print the same information in paragraph form; `lvdisplay -m` additionally shows the segment map — which PV's extents actually back each part of the LV. ## The order matters, and only in one direction You cannot skip a rung. There is no way to create an LV without a VG, and no way to add a disk to a VG without `pvcreate` first. Conversely, tearing down runs in reverse: unmount, `lvremove`, `vgremove`, `pvremove`. The payoff for all this ceremony is that the pool is now the unit you manage. Space that is free in the VG can be handed to whichever filesystem needs it, and a new disk becomes usable capacity for every LV in the group rather than a new mount point somebody has to find a use for.
- How would you find out how much unallocated space is left before creating another logical volume?`vgs` shows a `VFree` column — the extents in the volume group that no LV has claimed. `vgdisplay vg0` prints the same figure as "Free PE / Size" along with the extent count. `pvs` breaks it down per disk via `PFree`, which matters when you care *which* device the free space is on.
- What is the difference between lvcreate -L and lvcreate -l?`-L` takes a human size such as `200G` and LVM converts it to extents, rounding up to a whole extent. `-l` takes the extent count directly, or a percentage expression such as `100%FREE`, `50%VG` or `100%PVS`. `-l 100%FREE` is the usual way to consume exactly the remaining space without doing arithmetic.
- Can a single logical volume span two volume groups?No. The volume group is the allocation boundary: an LV is built only from extents belonging to PVs inside its own VG. If you need capacity from another disk, you add that disk to the same VG as a new PV rather than trying to bridge two groups.
Think of the PVs as sacks of flour, the VG as one big bin you empty them into, and the LVs as loaves you bake from the bin — the loaf no longer corresponds to any particular sack.
saying these in an interview costs you the question
- Thinks LVM by itself gives redundancy like RAID
- Says you run mkfs on the volume group
- Believes an LV cannot span more than one disk
- Skips pvcreate and passes a raw disk to vgcreate
- Calls the volume group a filesystem