Frequently Asked Questions

Volume Manager is specifically meant for Direct Attached Storage such as hard drives and solid-state drives in a “JBOD” configuration (Just a Bunch of Disks).

Avoid using Volume Manager with SAN- and NAS-based storage options, as they inherently involve extra network hops in the data path. This leads to poor performance and increased complexity.

HostPath volumes are ephemeral and are tied to the lifecycle of pods. Deleting or restarting a pod results in the removal of the HostPath volumes. This causes the loss of any data stored on the volumes.

Volume Manager volumes persist through both node and pod reboots. The associated Persistent Volume Claims (PVC) manage the lifecycle of a Volume Manager volume.

LocalPVs are statically provisioned from a local storage resource on the nodes that require persistent volumes. You must create the required LocalPVs prior to the workloads using them. For LocalPV, you must provide extensive user management for all stages, including creating the actual object resource for LocalPV.

Volume Manager also creates statically provisioned volume resources, but does not require user intervention for the creation of the object resource. Instead, Volume Manager dynamically provisions the persistent volume in response to a PVC requesting a Volume Manager storage volume. This significantly reduces complexity of management.

Volume Manager operates only on those disks which it explicitly manages.

For these managed disks, Volume Manager:

1. Selects disks local to the node where the pod is scheduled, providing direct access for the pods to the disks.

2. Runs a selection algorithm to choose a disk for a volume creation request.

3. Creates a sub-directory for the volume with quota set on the sub-directory for the requested volume size.

4. Publishes the volume to the pod.

Use kubectl directpv init to prepare the drives by formatting them with XFS filesystem and mounting them in a desired path (/var/lib/directpv/mnt/<uuid>). After successful mounting, Volume Manager can schedule volumes on these drives. To see initialized drives, use kubectl directpv list drives.

To initialize, a drive must have at least 512MB of space. The drive cannot have any of the following characteristics:

• Hidden

  (/sys/class/block/<device>/hidden should not be “1”.)

• Read-only

• Partitioned

• Held by other devices

  (/sys/class/block/<device>/holders should not have any entries.)

• Mounted

• Have swap-on enabled

• Be a CD-ROM

Volume Manager supports any storage resource presenting itself as a block device. While this includes LVMs (logical volume management), LUKs (Linux Unified Keys), LUNs (logical unit numbers), and similar virtualized drives, we do not recommend using Volume Manager with such devices in production environments.

This error occurs in the following situations:

• Kubernetes scheduled the pod on a node where Volume Manager doesn’t have any drives initialized. To correct this, use selectors in the workload to have Kubernetes schedule the pods on the desired set of nodes. Refer to the Kubernetes documentation on assigning pods to nodes for more details.
• You requested a zone, size, or other such parameter that Volume Manager cannot satisfy with an available initialized drive on the selected node. To correct this, change the parameter(s) in the workloads to an available set of values.

No, Volume Manager v4.0.0 and later removed support for direct-csi-min-io. After this release, Volume Manager does not provision any new volumes using the direct-csi-min-io storage class. However, the latest versions of Volume Manager continue to manage any existing volumes already provisioned using the direct-csi-min-io storage class.

To provision new volumes, use the directpv-min-io storage class. There are no functional or behavioral differences between direct-csi-min-io and directpv-min-io.

No, Volume Manager doesn’t support CSI snapshotting. Volume Manager is specifically meant for use cases where the application takes care of data availability and resiliency, such as AIStor. Applications using With the AWS S3 versioning APIs and internal healing do not require snapshots.

No, Volume Manager does not support ReadWriteMany. Volume Manager only supports ReadWriteOnce.

The workloads using Volume Manager run local to the node. Volume Manager provisions volumes from disks local in the node. This allows workloads to access the data path directly without any additional network hops, unlike remote volumes (network PVs).

Additional network hops from networked persistent volumes increases the complexity of the workload and may lead to poor performance.