This document is intended for application owners and platform administrators
that run Google Distributed Cloud. This document shows you how to create and use
storage classes for VMs that use VM Runtime on GDC. A StorageClass
lets you define different storage configurations to provide for the various
needs of your VMs.
Before you begin
To complete this document, you need access to Google Distributed Cloud version 1.12.0
(anthosBareMetalVersion: 1.12.0) or higher cluster. You can use any cluster
type capable of running workloads. If needed,
try Google Distributed Cloud on Compute Engine 
or see the
cluster creation overview.
Storage classes overview
You use a StorageClass to define the type of storage you make available to
VMs. Different storage classes might map to a different type of storage
hardware, file system, or performance. You can create and use storage classes to
support your compute workloads in VM Runtime on GDC. For more
information, see
Storage Classes.
A default StorageClass can be defined in the custom resource for
VM Runtime on GDC. If you don't define a specific class when you
create a VirtualMachineDisks, this default StorageClass is used. No initial
StorageClass is configured and set as default. In the following section, you
learn how to
set or update this default StorageClass.
Set or update the default StorageClass
Initially, Google Distributed Cloud with VM Runtime on GDC have no default
StorageClass configured. To create a VirtualMachineDisk without specifying a
StorageClass, you must first
create a StorageClass 
and then set it as default.
If you want to initially set or update the default StorageClass that
VM Runtime on GDC uses when you create a VirtualMachineDisk, update
the VMRuntime custom resource.
- Edit the - VMRuntimecustom resource:- kubectl edit vmruntime
- Add or update the - spec.storagesection that specifies the default- StorageClassto use:- apiVersion: vm.cluster.gke.io/v1 kind: VMRuntime metadata: name: vmruntime spec: enabled: true storage: defaultStorageClass: STORAGE_CLASS_NAME ...- Edit - STORAGE_CLASS_NAMEwith the name of the default- StorageClassyou want to use. If you need to first create a- StorageClass, see Create a- StorageClass.
- Save and close the - VMRuntimecustom resource in your editor.- The - StorageClassyou specified is now used when you now create a virtual machine disk and don't specify a- StorageClass. The following section shows you how to create a disk and use a specific StorageClass.- Existing - VirtualMachineDiskresources are not updated to use the newly specified- StorageClass.
Use a specific StorageClass
If you don't want to use the default StorageClass when you create a
VirtualMachineDisk, use the storageClassName field to specify a different
StorageClass.
To use a specific, already-defined StorageClass when you create a
VirtualMachineDisk, complete the following steps:
- Create a - VirtualMachineDiskmanifest, such as- my-disk.yaml, in the editor of your choice:- nano my-disk.yaml
- Copy and paste the following YAML manifest: - apiVersion: vm.cluster.gke.io/v1 kind: VirtualMachineDisk metadata: name: DISK_NAME spec: size: 10Gi storageClassName: STORAGE_CLASS_NAME- Replace the following values: - DISK_NAME: the name for your disk.
- STORAGE_CLASS_NAME: the- StorageClassto use for your disk. This- StorageClassmust already exist. If you need to first create a- StorageClass, see Create a StorageClass.
 
- Save and close the disk manifest in your editor. 
- Create the disk using - kubectl:- kubectl apply -f my-disk.yaml
Configure storage profiles
Storage profiles provide extra configuration options associated with each
StorageClass. These configuration options include which access mode and volume
mode to use for VirtualMachineDisks that use the StorageClass.
Without a configured storage profile, disks default to the ReadWriteOnce
access mode. This access mode isn't sufficient for production workloads, as
features like live migration don't work. The default volume mode without a
configured storage profile is Filesystem.
VM Runtime on GDC automatically generates one storage profile for
each StorageClass in a cluster. The storage profile is the same name as the
associated StorageClass. The following example output shows that the cluster
has four storage classes and associated profiles:
  $ kubectl get storageprofiles
  NAME            AGE
  anthos-system   11d
  node-disk       11d
  standard        11d
  nfs             11d
To edit a storage profile and change the access mode or volume mode, complete the following steps:
- Edit the - StorageProfilecustom resource for editing:- kubectl edit storageprofile STORAGE_PROFILE_NAME- Replace - STORAGE_PROFILE_NAMEwith the- StorageProfileyou want to edit.
- Add a single entry to the - spec.claimPropertySetslist of the- StorageProfile:- apiVersion: cdi.kubevirt.io/v1beta1 kind: StorageProfile metadata: name: nfs spec: claimPropertySets: - accessModes: - ACCESS_MODE volumeMode: VOLUME_MODE- The - accessModeand- volumeModeuse the underlying Kubernetes components. The values you set depend on the storage driver you use. Replace the following values as appropriate for the storage you use:- ACCESS_MODE: the access mode that you want to use. If supported by the associated- StorageClass, the preferred access mode is- ReadWriteMany.- Acceptable values include ReadWriteOnce,ReadOnlyMany,ReadWriteMany, andReadWriteOncePod. If not specified,ReadWriteOnceis used based on the VM Runtime on GDC defaults. For more information, see Access modes.
 
- Acceptable values include 
- VOLUME_MODE: the volume mode that you want to use.- Acceptable values include FilesystemandBlock. If not specified,Filesystemis used based on the Kubernetes defaults. For more information, see Volume modes.
 
- Acceptable values include 
 
- Save and close the - StorageProfilecustom resource in your editor.- The storage profile settings you defined are used when you now create any virtual disks. Existing - VirtualMachineDiskresources are not updated to use the defined storage profile settings.