Using VMware vSphere volumes for persistent storage - Configuring Persistent Storage | Installation and Configuration

Overview
Provisioning VMware vSphere volumes
- Creating persistent volumes
- Formatting VMware vSphere volumes

Overview

OKD supports VMware vSphere’s Virtual Machine Disk (VMDK) volumes. You can provision your OKD cluster with persistent storage using VMware vSphere. Some familiarity with Kubernetes and VMware vSphere is assumed.

The OKD persistent volume (PV) framework allows administrators to provision a cluster with persistent storage and gives users a way to request those resources without having any knowledge of the underlying infrastructure. vSphere VMDK volumes can be provisioned dynamically.

PVs are not bound to a single project or namespace; they can be shared across the OKD cluster. PV claims, however, are specific to a project or namespace and can be requested by users.

High availability of storage in the infrastructure is left to the underlying storage provider.

Prerequisites

Before creating PVs using vSphere, ensure your OKD cluster meets the following requirements:

OKD must first be configured for vSphere.
Each node host in the infrastructure must match the vSphere VM name.
Each node host must be in the same resource group.

Create VMDK using one of the following methods before using them.

Create using vmkfstools:

Access ESX through Secure Shell (SSH) and then use following command to create a VMDK volume:
```
vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk
```

Create using vmware-vdiskmanager:

shell vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk

Provisioning VMware vSphere volumes

Storage must exist in the underlying infrastructure before it can be mounted as a volume in OKD. After ensuring OKD is configured for vSphere, all that is required for OKD and vSphere is a VM folder path, file system type, and the PersistentVolume API.

Creating persistent volumes

You must define your PV in an object definition before creating it in OKD:

PV object definition using VMware vSphere example

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0001 (1)
spec:
  capacity:
    storage: 2Gi (2)
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  vsphereVolume: (3)
    volumePath: "[datastore1] volumes/myDisk" (4)
    fsType: ext4 (5)

1	The name of the volume. This must be how it is identified by PV claims or from pods.
2	The amount of storage allocated to this volume.
3	This defines the volume type being used (vsphereVolume plug-in, in this example). The `vsphereVolume` label is used to mount a vSphere VMDK volume into pods. The contents of a volume are preserved when it is unmounted. The volume type supports VMFS and VSAN datastore.
4	This VMDK volume must exist.
5	The file system type to mount (for example, `ext4`, `xfs`, and other file-systems).

Changing the value of the fsType parameter after the volume is formatted and provisioned can result in data loss and pod failure.

Save your definition to a file, for example vsphere-pv.yaml, and create the PV:
```
$ oc create -f vsphere-pv.yaml
  persistentvolume "pv0001" created
```

Verify that the PV was created:

$ oc get pv
NAME    LABELS  CAPACITY  ACCESSMODES   STATUS    CLAIM   REASON  AGE
pv0001  <none>  2Gi       RWO           Available                 2s

Now you can request storage using PV claims, which can now use your PV.

PV claims only exist in the user’s namespace and can only be referenced by a pod within that same namespace. Any attempt to access a PV from a different namespace causes the pod to fail.

Formatting VMware vSphere volumes

Before OKD mounts the volume and passes it to a container, it checks that the volume contains a file system as specified by the fsType parameter in the PV definition. If the device is not formatted with the file system, all data from the device is erased and the device is automatically formatted with the given file system.

This allows unformatted vSphere volumes to be used as PVs, because OKD formats them before the first use.