LVM enables flexible distribution of hard disk space over several physical volumes (hard disks, partitions, LUNs). It was developed because the need to change the segmentation of hard disk space might arise only after the initial partitioning has already been done during installation. Because it is difficult to modify partitions on a running system, LVM provides a virtual pool (volume group or VG) of memory space from which logical volumes (LVs) can be created as needed. The operating system accesses these LVs instead of the physical partitions. Volume groups can span more than one disk, so that several disks or parts of them can constitute one single VG. In this way, LVM provides a kind of abstraction from the physical disk space that allows its segmentation to be changed in a much easier and safer way than through physical repartitioning.

Figure 4.1, “Physical Partitioning versus LVM” compares physical partitioning (left) with LVM segmentation (right). On the left side, one single disk has been divided into three physical partitions (PART), each with a mount point (MP) assigned so that the operating system can access them. On the right side, two disks have been divided into two and three physical partitions each. Two LVM volume groups (VG 1 and VG 2) have been defined. VG 1 contains two partitions from DISK 1 and one from DISK 2. VG 2 contains the remaining two partitions from DISK 2.

Figure 4.1: Physical Partitioning versus LVM #

In LVM, the physical disk partitions that are incorporated in a volume group are called physical volumes (PVs). Within the volume groups in Figure 4.1, “Physical Partitioning versus LVM”, four logical volumes (LV 1 through LV 4) have been defined, which can be used by the operating system via the associated mount points (MP). The border between different logical volumes need not be aligned with any partition border. See the border between LV 1 and LV 2 in this example.

LVM features:

With these features, using LVM already makes sense for heavily used home PCs or small servers. If you have a growing data stock, as in the case of databases, music archives, or user directories, LVM is especially useful. It allows file systems that are larger than the physical hard disk. Another advantage of LVM is that up to 256 LVs can be added. However, keep in mind that working with LVM is different from working with conventional partitions.

You can manage new or existing LVM storage objects by using the YaST Partitioner. Instructions and further information about configuring LVM are available in the official LVM HOWTO (http://tldp.org/HOWTO/LVM-HOWTO/).

Important: Adding Multipath Support upon an Existing LVM Configuration

If you add multipath support after you have configured LVM, you must modify the /etc/lvm/lvm.conf file to scan only the multipath device names in the /dev/disk/by-id directory as described in Section 15.12, “Using LVM2 on Multipath Devices”, then reboot the server.

An LVM volume group (VG) organizes the Linux LVM partitions into a logical pool of space. You can carve out logical volumes from the available space in the group. The Linux LVM partitions in a group can be on the same or different disks. You can add partitions or entire disks to expand the size of the group. If you want to use an entire disk, it must not contain any partitions. If using partitions, they must not be mounted. YaST will automatically change their partition type to 0x8E Linux LVM when adding them to a VG.

A logical volume provides a pool of space similar to what a hard disk does. To make this space usable, you need to define physical volumes. A physical volume is similar to a regular partition—you can format and mount it.

Use The YaST Partitioner to create logical volumes from an existing volume group. Assign at least one logical volume to each volume group. You can create new logical volumes as needed until all free space in the volume group has been exhausted.

An LVM logical volume can optionally be thinly provisioned. Thin provisioning allows you to create logical volumes with sizes that overbook the available free space. You create a thin pool that contains unused space reserved for use with an arbitrary number of thin volumes. A thin volume is created as a sparse volume and space is allocated from a thin pool as needed. The thin pool can be expanded dynamically when needed for cost-effective allocation of storage space. Thinly provisioned volumes also support snapshots which can be managed with Snapper—see Chapter 4, System Recovery and Snapshot Management with Snapper, Administration Guide for more information.

Important

To use thinly provisioned volumes in a cluster, the thin pool and the thin volumes that use it must be managed in a single cluster resource. This allows the thin volumes and thin pool to always be mounted exclusively on the same node.

4.3.1 Thinly Provisioned Logical Volumes #

An LVM logical volume can optionally be thinly provisioned. Thin provisioning allows you to create logical volumes with sizes that overbook the available free space. You create a thin pool that contains unused space reserved for use with an arbitrary number of thin volumes. A thin volume is created as a sparse volume and space is allocated from a thin pool as needed. The thin pool can be expanded dynamically when needed for cost-effective allocation of storage space. Thinly provisioned volumes also support snapshots which can be managed with Snapper—see Chapter 4, System Recovery and Snapshot Management with Snapper, Administration Guide for more information.

To set up a thinly provisioned logical volume, proceed as described in Procedure 4.1, “Setting Up a Logical Volume”. When it comes to choosing the volume type, do not choose Normal Volume, but rather Thin Volume or Thin Pool.

Thin pool

The logical volume is a pool of space that is reserved for use with thin volumes. The thin volumes can allocate their needed space from it on demand.

Thin volume

The volume is created as a sparse volume. The volume allocates needed space on demand from a thin pool.

Important: Thinly Provisioned Volumes in a Cluster

To use thinly provisioned volumes in a cluster, the thin pool and the thin volumes that use it must be managed in a single cluster resource. This allows the thin volumes and thin pool to always be mounted exclusively on the same node.

The space provided by a volume group can be expanded at any time in the running system without service interruption by adding more physical volumes. This will allow you to add logical volumes to the group or to expand the size of existing volumes as described in Section 4.5, “Resizing a Logical Volume”.

It is also possible to reduce the size of the volume group by removing physical volumes. YaST only allows to remove physical volumes that are currently unused. To find out which physical volumes are currently in use, run the following command. The partitions (physical volumes) listed in the PE Ranges column are the ones in use:

tux > sudo pvs -o vg_name,lv_name,pv_name,seg_pe_ranges
root's password:
  VG   LV    PV         PE Ranges       
             /dev/sda1                  
  DATA DEVEL /dev/sda5  /dev/sda5:0-3839
  DATA       /dev/sda5                  
  DATA LOCAL /dev/sda6  /dev/sda6:0-2559
  DATA       /dev/sda7                  
  DATA       /dev/sdb1                  
  DATA       /dev/sdc1

In case there is unused free space available in the volume group, you can enlarge a logical volume to provide more usable space. You may also reduce the size of a volume to free space in the volume group that can be used by other logical volumes.

Note: “Online” Resizing

When reducing the size of a volume, YaST automatically resizes its file system, too. Whether a volume that is currently mounted can be resized “online” (that is while being mounted), depends on its file system. Growing the file system online is supported by Btrfs, XFS, Ext3, and ReiserFS.

Shrinking the file system online is only supported by Btrfs. In order to shrink XFS, Ext2/3/4, and ReiserFS volumes, you need to unmount them. Shrinking volumes formatted with XFS is not possible at all, since XFS does not support file system shrinking.

For information about using LVM commands, see the man pages for the commands described in the following table. All commands need to be executed with root privileges. Either use sudo command (recommended) or execute them directly as root.

Table 4.1: LVM Commands #

Command	Description
pvcreate device	Initializes a device (such as /dev/sdb) for use by LVLM as a physical volume.
pvdisplay device	Displays information about the LVM physical volume, such as whether it is currently being used in a logical volume.
vgcreate -c y vg_name dev1 [dev2...]	Creates a clustered volume group with one or more specified devices.
vgchange -a [ey|n] vg_name	Activates (-a ey) or deactivates (-a n) a volume group and its logical volumes for input/output. Important: Activating a Volume in a Cluster Ensure that you use the ey option to exclusively activate a volume group on a cluster node. This option is used by default in the load script.
vgremove vg_name	Removes a volume group. Before using this command, remove the logical volumes, then deactivate the volume group.
vgdisplay vg_name	Displays information about a specified volume group. To find the total physical extent of a volume group, enter vgdisplay vg_name | grep "Total PE"
lvcreate -L size -n lv_name vg_name	Creates a logical volume of the specified size.
lvcreate -L size --thinpool pool_name vg_name	Creates a thin pool named myPool of the specified size from the volume group vg_name. The following example creates a thin pool with a size of 5 GB from the volume group LOCAL: lvcreate -L 5G --thinpool myPool LOCAL
lvcreate -T vg_name/pool_name -V size \ -n lv_name	Creates a thin logical volume within the pool pool_name. The following example creates a 1GB thin volume named myThin1 from the pool myPool on the volume group LOCAL: lvcreate -T LOCAL/myPool -V 1G -n myThin1
lvcreate -T vg_name/pool_name -V size -L size \ -n LV_name	It is also possible to combine thin pool and thin logical volume creation in one command: lvcreate -T LOCAL/myPool -V 1G -L 5G -n myThin1
lvcreate -s [-L size] -n snap_volume \ source_volume_path vg_name	Creates a snapshot volume for the specified logical volume. If the size option (-L or --size) is not included, the snapshot is created as a thin snapshot.
lvremove /dev/vg_name/lv_name	Removes a logical volume. Before using this command, close the logical volume by dismounting it with the umount command.
lvremove snap_volume_path	Removes a snapshot volume.
lvconvert --merge snap_volume_path	Reverts the logical volume to the version of the snapshot.
vgextend vg_name device	Adds the specified device (physical volume) to an existing volume group.
vgreduce vg_name device	Removes a specified physical volume from an existing volume group. Important Ensure that the physical volume is not currently being used by a logical volume. If it is, you must move the data to another physical volume by using the pvmove command.
lvextend -L size /dev/vg_name/lv_name	Extends the size of a specified logical volume. Afterwards, you must also expand the file system to take advantage of the newly available space. See Chapter 2, Resizing File Systems for details.
lvreduce -L size /dev/vg_name/lv_name	Reduces the size of a specified logical volume. Important Ensure that you reduce the size of the file system first before shrinking the volume, otherwise you risk losing data. See Chapter 2, Resizing File Systems for details.
lvrename /dev/vg_name/lv_name \ /dev/vg_name/new_lv_name	Renames an existing LVM logical volume. It does not change the volume group name.

sudo lvextend −L +10G /dev/LOCAL/DATA
sudo btrfs filesystem resize +10G /dev/LOCAL/DATA

sudo btrfs filesystem resize -size 5G /dev/LOCAL/DATA
sudo lvreduce /dev/LOCAL/DATA

A tag is an unordered keyword or term assigned to the metadata of a storage object. Tagging allows you to classify collections of LVM storage objects in ways that you find useful by attaching an unordered list of tags to their metadata.

tags {
   # Enable hostname tags
   hosttags = 1
}

tags {

   tag1 { }
      # Tag does not require a match to be set.

   tag2 {
      # If no exact match, tag is not set.
      host_list = [ "hostname1", "hostname2" ]
   }
}

  activation {
      volume_list = [ "vg1/lvol0", "@database" ]
  }