mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
54 lines
3.2 KiB
Plaintext
54 lines
3.2 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * microshift_storage/volume-snapshots-microshift.adoc
|
|
|
|
:_mod-docs-content-type: CONCEPT
|
|
[id="microshift-lvm-thin-volumes_{context}"]
|
|
= About LVM thin volumes
|
|
|
|
To use advanced storage features such as creating volume snapshots or volume cloning, you must perform the following actions:
|
|
|
|
* Configure both the logical volume manager storage (LVMS) provider and the node.
|
|
* Provision a logical volume manager (LVM) thin-pool on the {op-system-ostree} host.
|
|
* Attach LVM thin-pools to a volume group.
|
|
|
|
[IMPORTANT]
|
|
====
|
|
To create Container Storage Interface (CSI) snapshots, you must configure thin volumes on the {op-system-ostree} host. The CSI does not support volume shrinking.
|
|
====
|
|
|
|
[IMPORTANT]
|
|
====
|
|
When using thin provisioning, it is important that you monitor the storage pool and add more capacity as the available physical space runs out. You can configure the storage pool to auto expand when there is available space within the volume group (VG). See link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/configuring_and_managing_logical_volumes/index#creating-thinly-provisioned-logical-volumes_creating-and-managing-thin-provisioned-volumes[Creating thinly provisioned logical volumes].
|
|
====
|
|
|
|
For LVMS to manage thin logical volumes (LVs), a thin-pool `device-class` array must be specified in the `etc/lvmd.yaml` configuration file. Multiple thin-pool device classes are permitted.
|
|
|
|
If additional storage pools are configured with device classes, then additional storage classes must also exist to expose the storage pools to users and workloads. To enable dynamic provisioning on a thin-pool, a `StorageClass` resource must be present on the node. The `StorageClass` resource specifies the source `device-class` array in the `topolvm.io/device-class` parameter.
|
|
|
|
.Example `lvmd.yaml` file that specifies a single device class for a thin-pool
|
|
[source, yaml]
|
|
----
|
|
socket-name: <1>
|
|
device-classes: <2>
|
|
- name: thin <3>
|
|
default: true
|
|
spare-gb: 0 <4>
|
|
thin-pool:
|
|
name: thin
|
|
overprovision-ratio: 1 <5>
|
|
type: thin <6>
|
|
volume-group: ssd <7>
|
|
----
|
|
<1> String. The UNIX domain socket endpoint of gRPC. Defaults to `/run/lvmd/lvmd.socket`.
|
|
<2> A list of maps for the settings for each `device-class`.
|
|
<3> String. The unique name of the `device-class`.
|
|
<4> Unsigned 64-bit integer. Storage capacity in GB to be left unallocated in the volume group. Defaults to `0`.
|
|
<5> Specify a float factor by which you can provision additional storage based on the available storage in the thin pool. For example, if this field is set to 10, you can provision up to 10 times the amount of available storage in the thin pool. To disable over-provisioning, set this field to `1`.
|
|
<6> Thin provisioning is required to create volume snapshots.
|
|
<7> String. The group where the `device-class` creates the logical volumes.
|
|
|
|
[IMPORTANT]
|
|
====
|
|
When multiple PVCs are created simultaneously, a race condition prevents LVMS from accurately tracking the allocated space and preserving the storage capacity for a device class. Use separate volume groups and device classes to protect the storage of highly dynamic workloads from each other.
|
|
==== |