# pvs

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/pvs

## Quick definition

In Linux, pvs (physical volumes) are the actual hard drives or partitions that form the building blocks for Logical Volume Manager (LVM). LVM allows you to combine multiple physical volumes into a single storage pool, then create flexible virtual disks called logical volumes that can be resized, moved, or snapped without downtime. Understanding pvs is essential for managing modern server storage efficiently.

## Simple meaning

Think of a physical volume (pvs) like a single Lego brick. Each brick is a solid, separate piece, just as each hard drive or disk partition is a physical storage unit. But if you want to build something bigger and more flexible-like a spaceship or castle-you need to combine many bricks. LVM works by taking these pvs (the bricks) and gluing them into a larger structure called a volume group. This volume group acts like a big box of modular plastic where you can pull out or add bricks anytime. Then, from that box, you create logical volumes-these are the final shapes you actually use, like a partition for your documents or a virtual drive for a database.

Without pvs, you would be stuck with the original size of your hard drive. If you needed more space, you would have to buy a new drive, copy everything over, and reconfigure your system. LVM with pvs lets you just add another physical volume (another drive) to the volume group and then extend the logical volume while the system is still running. This flexibility is why nearly all serious enterprise servers, cloud infrastructure, and even modern desktop Linux distributions use LVM.

To manage pvs, you use commands like pvcreate, pvdisplay, pvscan, and pvremove. These tools tell Linux which disks or partitions to treat as physical volumes, showing their size, status, and which volume group (if any) they belong to. The process is straightforward: you partition a disk, mark it as a physical volume with pvcreate, then add it to a volume group with vgextend. From there, you can create logical volumes with lvcreate and format them with a filesystem.

In short, pvs transform a rigid physical disk into a flexible, logical building block. They are the foundation layer of LVM-the part that turns hardware into a dynamic storage resource.

## Technical definition

A physical volume (pvs) is a storage device or partition that has been initialized for use by the Linux Logical Volume Manager (LVM2). The initialization process writes an LVM metadata label to a specific location on the device-typically the second 512-byte sector (sector 1) or at the beginning of the device in the first 4 KiB. This label identifies the device as a pv, records the volume group (VG) it belongs to (if any), and stores metadata about the physical extents (PEs) that make up the pv.

Internally, a pv is divided into small, fixed-size chunks called physical extents. The default PE size is 4 MiB, but this can be set from 1 KiB to 128 GiB at the time of volume group creation. Each PE is the smallest allocatable unit for logical volumes. When you create a logical volume, LVM maps logical extents (LEs) from the LV to physical extents on one or more pvs. This mapping is stored in the metadata area of the pv and mirrored across multiple pvs for redundancy.

The LVM metadata contains: a volume group descriptor area (VGDA) that lists the VG UUID, the pv UUID, the list of all pvs in the VG, the list of all LVs, and the mapping of LE to PE. LVM2 uses a circular, self-consistent metadata format that is updated atomically. This means that if a crash occurs during a write, the metadata remains consistent by rolling back to the previous version.

Commands for managing pvs include: pvcreate (initialize a device), pvdisplay (show detailed info), pvscan (scan all devices for pvs), pvresize (resize the pv to match underlying device size), pvmove (move extents between pvs within the same VG), and pvremove (remove the LVM label). The pvcreate command writes the label and optionally can be run with the --metadatasize flag to control the metadata area size.

Physical volumes can be entire disks (e.g., /dev/sdb), partitions (e.g., /dev/sda2), or even loopback devices, software RAID arrays, or iSCSI LUNs. The key requirement is that the device must be a block device and must not be in use by a filesystem directly (unless you want to reuse it). LVM does not place restrictions on the size of a pv, but practical limits are dictated by the kernel and the metadata format.

In enterprise environments, pvs are often used with storage area networks (SAN) where many LUNs are presented to a host. Each LUN becomes a pv, grouped into a large VG, and then carved into LVs for databases, virtual machine disk images, or application data. This abstraction simplifies storage management, allowing administrators to extend storage without rebooting or unmounting.

Troubleshooting pvs commonly involves checking pv display for missing devices, duplicate UUIDs, or orphaned pvs after a VG is removed. The pvscan command with --uuid shows metadata. If a pv fails (disk failure), LVM marks the pv as missing, and the VG becomes partially available. Using pvmove or replacing the failed disk and restoring from backup are standard recovery procedures.

## Real-life example

Imagine you are organizing a large shared wardrobe for your family. Every person has their own drawer (like a physical disk). The problem is, one child has a tiny drawer that gets full fast, and another has a huge one that is nearly empty. You cannot easily swap clothes between drawers because they are fixed sizes. This is like having fixed-size partitions on a hard drive.

Now, suppose you buy a set of modular plastic bins that all lock together. You start with three bins (like three physical disks or partitions). You label each bin as a “physical volume” (pvs). Then, you connect them all into one giant rack (the volume group). Even though each bin is separate, they act as one combined storage. Now, you can allocate space from this giant rack to make logical “drawers” (logical volumes) for each family member. If one person needs more space, you just add another bin (pv) to the rack and allocate more from it-without moving anyone’s clothes.

In the IT world, your “wardrobe” is a server’s storage. The bins are your physical disks (HDDs, SSDs, or partitions). The LVM software is the rack system that holds them together. pvs are the individual bins. Without them, you would have to commit to a fixed-size drawer for each application. With pvs, everything becomes flexible.

Let’s say your database server is running low on space. You have a spare hard drive (new bin). You plug it in, use pvcreate to initialize it as a physical volume, then vgextend to add it to the volume group. Finally, you run lvextend to grow the database’s logical volume. The database never goes offline. This is the power of pvs in real life.

## Why it matters

Understanding pvs is critical for any IT professional managing Linux servers, because storage is the backbone of every application. Without LVM and pvs, system administration becomes rigid and error-prone. pvs allow you to abstract away physical hardware limitations. In a cloud environment, you often have to add storage to a running instance. LVM with pvs makes that possible without rebooting or reconfiguring applications.

For system reliability, pvs enable snapshot-based backup. You can take a snapshot of a logical volume at a point in time, which relies on the underlying pvs being part of a volume group. This is used for consistent database backups or before applying risky updates. If the snapshot consumes too much space, you can even add another pv to the volume group to give the snapshot room.

Performance tuning also ties into pvs. You can use pvmove to relocate active extents from a slow disk to a faster SSD without downtime. This is called storage tiering and is a common technique in enterprise environments. Knowing how to configure pvs with different devices (like using SSDs for hot data and HDDs for cold data) is a valuable skill.

Cost management matters too. Instead of buying a single large disk, you can combine several smaller, cheaper disks into a volume group using pvs. This reduces hardware costs and extends the life of existing equipment. It also simplifies procurement: you can add storage incrementally as needed.

Security and auditing also benefit. LVM metadata tracks which pvs belong to which VG and LV. This makes it easier to manage storage allocation and identify which disk holds a particular logical volume. In regulated environments, this traceability is essential.

pvs are the atoms of LVM storage. Without them, logical volumes and volume groups cannot exist. For IT certification learners, mastering pvs is a stepping stone to understanding advanced storage topics like RAID, thin provisioning, and clustered storage.

## Why it matters in exams

pvs is a core topic in the Linux Professional Institute (LPI) exams (especially LPIC-1 and LPIC-2), Red Hat Certified System Administrator (RHCSA), and CompTIA Linux+ (XK0-004 and XK0-005). In these exams, candidates are expected to know how to create, display, extend, and remove physical volumes. The RHCSA exam specifically includes objectives like “Configure and manage LVM storage” and “Add new physical volumes to a volume group.”

In the RHCSA (EX200) exam, you might be asked to extend the root filesystem. That requires you to first create a partition, initialize it as a pv with pvcreate, add it to the volume group with vgextend, and then extend the logical volume with lvextend. The exam expects you to know the exact commands and the order of operations. Mistakes like running lvextend before adding the pv to the VG will cause errors.

In LPIC-1 (101-500), the topic “102.2 Install and configure a system as a LVM” covers pvs, volume groups, and logical volumes. Questions may ask about the purpose of pvcreate, the location of the LVM label, or how to move extents between pvs. Multiple-choice questions often test your understanding of what a pv can be (whole disk, partition, loop device) and what it cannot be (a mounted filesystem, a swap partition in use).

CompTIA Linux+ (XK0-005) also includes LVM in domain 3 (Storage Management). Candidates must know how to interpret output from pvdisplay and pvscan. Scenario-based questions may present a situation where a volume group is missing a pv and ask you to identify the correct recovery step. For example, if a disk fails, the pv is marked as missing; the correct action is to replace the disk, run pvcreate on the new disk, and then vgreduce --removemissing or restore metadata from backup.

In all these exams, pvs are foundational. You cannot understand LVM without understanding pvs. Questions that test pv concepts often have distractors like confusing pv with VG or LV. For example, a question might ask, “Which command initializes a partition for use by LVM?” with options pvcreate, vgcreate, lvcreate, and mkfs. The correct answer is pvcreate, because that is the only command that writes the LVM label.

Exams also test the distinction between pvs and physical extents. You might need to know that pvdisplay shows the total number of PEs, while vgdisplay shows free PEs per VG. A question might ask how to find out how many physical extents are used on a specific disk. The answer is to run pvdisplay on that pv.

For the highest-level exams (LPIC-2, RHCE), pvs are still relevant in the context of advanced LVM features like RAID logical volumes, thin pools, and caching. But for entry-level certifications, focus on creation, display, and extension. Knowing the pvs command (a synonym for pvdisplay) is also useful for quick checks during exams.

## How it appears in exam questions

LVM questions on certification exams often follow a scenario-based format where you have a system with limited storage and must expand it. For instance, “You have a server with a 50 GB root logical volume that is 95% full. A new 20 GB disk has been added. What is the correct sequence of commands to extend the root LV without downtime?” The expected answer involves pvcreate on the new disk, vgextend on the volume group, lvextend on the LV, and then resizing the filesystem (xfs_growfs or resize2fs). Many candidates forget the last step, so exam traps focus on that.

Another common pattern is troubleshooting a failing disk. “You notice that a volume group has a missing physical volume. Which command shows the status of the pv? And what is the next step to recover?” The answer is pvdisplay or pvs to see the missing flag, then replace the disk and use pvmove or vgreduce --removemissing if the data is not needed.

There are also configuration questions: “You want to combine two 10 GB disks into one 20 GB volume group. Which command do you run on each disk first?” The answer is pvcreate. The trap is vgcreate, which creates the VG but does not initialize the disks-it only works if the pvs already exist.

Multiple-choice questions sometimes ask about the size of physical extents: “The default PE size in LVM2 is:” 4 MiB. This is a straightforward fact that candidates must memorize.

Another variant: “You need to move data off a failing disk to another disk in the same volume group. Which command do you use?” pvmove is the correct answer. The trap is using cp or dd, which do not respect LVM metadata.

Scenario questions also test error messages. For example, “You try to pvcreate a partition that is already mounted. What happens?” The command will fail with a warning about the device being in use. The correct approach is to unmount it first or use --force (discouraged).

Finally, some questions ask about output interpretation. “Given the output of pvdisplay, what is the total number of physical extents?” Or “How many extents are free?” Knowing the fields of pvdisplay is essential.

## Example scenario

You are the system administrator for a small company’s web server. The server runs Ubuntu Server 20.04 LTS with LVM. It currently has one 120 GB SSD as its only physical volume, named /dev/sda5, belonging to a volume group called vg_webserver. The volume group contains two logical volumes: lv_root (30 GB) for the operating system, and lv_data (70 GB) for website files and databases. Over time, the data logical volume has grown to 85% full, and the company is expecting a major marketing campaign that will add 20 GB of data.

You check the server and find there is an empty drive bay. You install a new 240 GB SSD (detected as /dev/sdb). To add space, you must first create a partition on /dev/sdb using fdisk or gdisk. You create a single partition /dev/sdb1 of type “Linux LVM” (code 8e in MBR, or code E6D6D379-F507-44C2-A23C-238F2A3DF928 in GPT). Then you initialize it as a physical volume with:

sudo pvcreate /dev/sdb1

This command writes the LVM label and metadata to /dev/sdb1. Next, you add this new pv to the existing volume group:

sudo vgextend vg_webserver /dev/sdb1

Now the volume group has 360 GB total (120 + 240). You extend the logical volume for data:

sudo lvextend -L +20G /dev/vg_webserver/lv_data

Finally, you resize the filesystem (assuming it is ext4):

sudo resize2fs /dev/vg_webserver/lv_data

The website’s storage is now expanded without any downtime. The new physical volume /dev/sdb1 integrates into the existing storage pool. This scenario shows exactly how pvs are used in a real administration task.

## Common mistakes

- **Mistake:** Running pvcreate on a mounted or in-use partition.
  - Why it is wrong: The LVM tools will refuse or risk corrupting data if the device is active. If forced, it can destroy existing filesystems.
  - Fix: Always unmount the filesystem or ensure no process is using the device before running pvcreate. Use lsof or fuser to check.
- **Mistake:** Confusing pvcreate with vgcreate. Running vgcreate first without initializing pvs.
  - Why it is wrong: vgcreate expects the disks to already be physical volumes. If you run vgcreate on raw disks, it returns an error.
  - Fix: Always initialize disks with pvcreate, then create the volume group with vgcreate.
- **Mistake:** Forgetting to resize the filesystem after extending the logical volume.
  - Why it is wrong: lvextend increases the LV capacity, but the filesystem still sees the old boundaries. The extra space is unusable.
  - Fix: After lvextend, run resize2fs for ext4 or xfs_growfs for XFS.
- **Mistake:** Using the wrong partition type or no partition type for LVM.
  - Why it is wrong: Without the correct partition type code (8e for MBR, or certain GPT GUID), some systems may not recognize the partition for LVM, and boot loaders may behave unexpectedly.
  - Fix: Set the partition type to “Linux LVM” using your partitioning tool before running pvcreate.
- **Mistake:** Trying to remove a physical volume that is still in use by a volume group without first deallocating extents.
  - Why it is wrong: pvremove on a pv that is part of a VG will fail because the VG holds metadata on that pv. The command only works if the pv is not a member.
  - Fix: Use pvmove to move all extents off the pv to another pv in the VG, then vgreduce to remove it from the VG, and finally pvremove.
- **Mistake:** Assuming pvs works only with entire disks, ignoring loop devices or partitions.
  - Why it is wrong: LVM can work with any block device. Not knowing this can lead to missing valid options in exam scenarios.
  - Fix: Remember that pvcreate can be used on partitions, full disks, loop devices, and even software RAID arrays.
- **Mistake:** Misinterpreting pvdisplay output, especially confusing “PV Size” with “Allocatable” status.
  - Why it is wrong: A pv can be part of a VG but have a status of “not allocatable,” which means it cannot hold new extents. This is often due to metadata corruption or missing VG.
  - Fix: Check “Allocatable” field in pvdisplay. If it says “NO,” it is not usable for allocation until fixed (usually by repairing metadata).

## Exam trap

{"trap":"In an exam question, a candidate is asked: “To add a new disk to an existing LVM volume group, which command should be run first?” The options include pvcreate, vgcreate, lvcreate, and mkfs. Many learners choose vgcreate because they think they are creating the volume group, but the correct answer is pvcreate because the disk must be initialized as a physical volume first.","why_learners_choose_it":"Learners confuse the order of operations. They see “add a disk to an existing volume group” and think the first step is to modify the volume group (vgcreate or vgextend). They forget that the disk itself must first be marked as usable by LVM.","how_to_avoid_it":"Memorize the sequence: first partition the disk (if needed), then pvcreate, then vgextend, then lvextend, then filesystem resize. Remember pvcreate always comes before vgcreate or vgextend. Use the mnemonic: “Physical first, Volume second, Logical third, Filesystem fourth.”"}

## Commonly confused with

- **pvs vs Volume Group (VG):** A volume group is the pool that contains multiple physical volumes and from which logical volumes are created. pvs are the underlying disks; the VG is the container. You can have many pvs in one VG, but one pv can belong to only one VG at a time. (Example: Think of pvs as individual Lego bricks, and the VG as the completed baseplate you build on. You add bricks (pvs) to the baseplate (VG) to build your structure.)
- **pvs vs Logical Volume (LV):** A logical volume is a virtual block device that LVM creates from the space available in a volume group. Unlike pvs, LVs are not tied to a specific physical disk-they can span multiple pvs. pvs are the physical storage, LVs are the flexible partitions you actually format and use. (Example: The pvs are the ingredients (flour, eggs, sugar), the VG is the mixing bowl, and the LV is the cake you bake from the mixture.)
- **pvs vs Physical Extent (PE):** A physical extent is a small, fixed-size chunk (default 4 MiB) into which a physical volume is divided. While the pv is the whole disk, each PE is a tiny segment of it. LVM maps logical extents to PEs. You manage pvs, but the allocation happens in PEs. (Example: A pizza (the pv) is cut into slices (PEs). You cannot allocate the whole pizza at once-you distribute slices to different logical volumes.)
- **pvs vs Partition:** A partition is a section of a hard drive created with tools like fdisk. You can turn a partition into a pv using pvcreate. But not all partitions are pvs; a partition can hold a filesystem directly without LVM. A pv is specifically a partition (or whole disk) initialized with LVM metadata. (Example: An empty lot (partition) can be turned into a parking lot (pvs) by adding markings (LVM label). Without markings, it's just a dirt lot.)

## Step-by-step breakdown

1. **Identify the device** — Use lsblk, fdisk -l, or lsscsi to list available block devices. Choose a disk or partition that is not in use. For a new disk, you may need to create a partition first (optional but recommended).
2. **Initialize the device as a physical volume** — Run pvcreate /dev/sdX (or /dev/sdX1). This writes the LVM label to the device and prepares it for use in a volume group. The metadata area stores UUIDs and extent maps.
3. **Verify the physical volume** — Run pvdisplay /dev/sdX or pvs to confirm the pv was created. Note the PV UUID, size, and available physical extents. This step ensures the device is ready.
4. **Add the physical volume to a volume group** — If a volume group already exists, run vgextend <vgname> /dev/sdX. If not, create a new VG with vgcreate <vgname> /dev/sdX. Now the pv contributes its space to the pool.
5. **Create or extend a logical volume using the pv** — To use the new space, either create a new LV with lvcreate or extend an existing LV with lvextend. LVM automatically allocates extents from all pvs in the VG, including the new one.
6. **Resize the filesystem (if extending an existing LV)** — After extending the LV, the filesystem still only sees the old size. Run resize2fs /dev/<vg>/<lv> for ext4 or xfs_growfs /mountpoint for XFS. Without this step, the extra space is invisible to applications.
7. **Optionally move extents for performance or replacement** — If you need to move data off a pv, use pvmove /dev/sdX. This relocates all used extents to other pvs in the VG. After moving, you can safely remove the pv with vgreduce and pvremove.

## Practical mini-lesson

Let us walk through a real-world task: adding a new 100 GB SSD to a database server that is running out of space. The server already uses LVM with a volume group named vg_db and logical volumes for data (lv_data) and logs (lv_log). The new disk appears as /dev/sdc.

First, check the current state with pvs and vgs. This shows you which pvs exist and how full the VG is. Next, create a partition on /dev/sdc using fdisk. Set the partition type to 8e (Linux LVM). Then initialize it: pvcreate /dev/sdc1. Verify with pvdisplay. Now add it to vg_db: vgextend vg_db /dev/sdc1. The VG size increases immediately.

Now you want to extend lv_data by 50 GB. Run: lvextend -L +50G /dev/vg_db/lv_data. If the LV uses ext4, you must then resize the filesystem: resize2fs /dev/vg_db/lv_data. For XFS, run xfs_growfs /mount/point. The database can now use the extra space.

What can go wrong? If the new pv has a different extent size (PE size) than the existing VG, vgextend will fail. The PE size is set when the VG is created (default 4 MiB). All pvs must use the same PE size. To avoid this, always create pvs against the same VG or specify --physicalextentsize when creating the VG.

Another common issue is running out of free extents on the VG even though you added a new pv. This could happen if the VG is full and the new pv was not added correctly. Check with vgdisplay for “Free PE.” If it shows 0, the pv may not have been added, or the VG already had no space but the pv was added but has no free extents (very rare). In that case, run pvdisplay to see if the pv is completely empty.

For exam purposes, also practice removing a pv. Suppose you need to decommission the old 50 GB HDD (pvs). First, use pvmove /dev/sdb to move all extents to /dev/sdc1. Then vgreduce vg_db /dev/sdb, and finally pvremove /dev/sdb to remove the LVM label. This is a safe process with zero downtime if done correctly.

In production, always test on a VM first. LVM operations are powerful but can be dangerous if you accidentally delete a VG or pv. Backup metadata with vgcfgbackup before any risky operation. This mini lesson includes the exact commands and pitfalls professionals face.

## Memory tip

Remember: “Physical first, Volume second, Logical third, Filesystem fourth” for the correct order of LVM operations.

## FAQ

**Can I create a physical volume on an entire disk without partitioning?**

Yes, you can run pvcreate directly on a whole disk (e.g., /dev/sdb). However, partitioning is recommended for compatibility and to prevent accidental reuse by other tools.

**What does pvdisplay show that pvs does not?**

pvdisplay shows detailed information including the number of physical extents, PE size, and allocation policy. pvs shows a summary with less detail, ideal for quick checks.

**Can I use a physical volume as a regular filesystem without LVM?**

Once you run pvcreate, the LVM label occupies the first few sectors. To use it as a regular filesystem, you must remove the label with pvremove and then recreate a filesystem (e.g., with mkfs).

**What happens if I lose a physical volume in a volume group?**

The volume group becomes degraded. Logical volumes that have extents on that pv become inaccessible. You can replace the pv and restore data from backup or use pvmove if the disk is still readable.

**Is it possible to change the PE size after creating a physical volume?**

No, the PE size is set at volume group creation time and cannot be changed later without recreating the VG. You must back up data and start over.

**How do I check if a disk is already a physical volume?**

Run pvscan or pvs. If the disk appears in the output, it is a physical volume. You can also use blkid to see the LVM label.

**Can I use pvcreate on a disk that already has data?**

Yes, but pvcreate overwrites the first few sectors, effectively destroying any existing filesystem. Always backup data first. Use pvcreate with caution.

**What is the difference between pvcreate and pvscan?**

pvcreate initializes a device as a physical volume. pvscan scans all block devices for existing LVM labels and displays them. They serve different purposes: creation versus discovery.

## Summary

pvs (physical volumes) are the foundation of Linux LVM storage management. They transform raw disks or partitions into flexible building blocks that can be grouped into volume groups and carved into resizable logical volumes. Understanding pvs is essential for system administrators who need to manage growing storage without downtime. Certification exams for RHCSA, LPIC-1, and CompTIA Linux+ heavily test pv concepts, commands, and troubleshooting.

Remember that pvcreate initializes a device, pvdisplay shows its details, and vgextend adds it to a volume group. The most common mistake is forgetting to resize the filesystem after extending a logical volume. The correct order is: pvcreate, vgextend, lvextend, then resize filesystem. When a pv fails, use pvmove to relocate extents before removal. pvs are not the same as partitions, logical volumes, or volume groups, but they work together seamlessly.

For exam success, practice with commands in a virtual lab. Understand the output of pvdisplay and pvs. Know that the default PE size is 4 MiB. And always check that a pv has free extents before trying to allocate a logical volume. With a solid grasp of pvs, you will be well-prepared for storage questions in any general IT certification.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/pvs