Author: Brandon B. Jozsa

This article is part of a larger OpenShift Operators series, with the goal of providing quick information about installing using Red Hat's official operators.

Table of Contents

- Introduction
- Part I: Preparation
- Part II: Operator Installation
- Modifying the Storage Profile for LVM Deployments
- Part III: Customization
- Part IV: StorageClass Enhancements (Optional)
- Final Thoughts

Introduction

This article will cover the basics of OpenShift Virtualization for lab use. It will provide quick and concise information for installing and configuring OpenShift Virtualization specifically, however you will often find it referenced for larger and more detailed use cases throughout this website as well.

Currently documented version: 4.16

Part I: Requirements

OpenShift Virtualization will require a CSI-compliant storage. Two of the most popular are:

Logical Volume Manager (for SNO deployments)
OpenShift Data Foundation (for multi-node deployments)

Once this requirement is met, you must have the following annotation configured: storageclass.kubevirt.io/is-default-virt-class=true

STORAGECLASS="lvms-vg1-immediate"

oc patch storageclass $STORAGECLASS -p '{"metadata": {"annotations":{"storageclass.kubevirt.io/is-default-virt-class":"true"}}}'

Part II: Installation

Be sure that you've completed the requirements above before continuing.

Use the following deployment to install the OpenShift Virtualization operator via the CLI. This includes three (3) common manifests: a Namespace, an OperatorGroup, and a Subscription.

oc apply -f - <<EOF
---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-cnv

---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: kubevirt-hyperconverged-group
  namespace: openshift-cnv
spec:
  targetNamespaces:
    - openshift-cnv

---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: hco-operatorhub
  namespace: openshift-cnv
spec:
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  name: kubevirt-hyperconverged
  startingCSV: kubevirt-hyperconverged-operator.v4.16.2
  channel: "stable"
EOF

Next, apply the following HyperConverged CR to your cluster to install OpenShift Virtualization.

oc apply -f - <<EOF
kind: HyperConverged
apiVersion: hco.kubevirt.io/v1beta1
metadata:
  annotations:
    deployOVS: 'false'
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec: {}
EOF

Modifying the Storage Profile for LVM Deployments

NOTICE: The following information is only relevant if you've deployed LVM Storage (typically for SNO deployments). ODF does not require the following the following changes.

Have you noticed that VMs start slowly when using OCPV on SNO deployments? The following section will help!

Modifying the StorageProfile will improve the overall speed/performance of starting virtual machines on OCPV. By default, OpenShift Data Foundation (ODF) creates a StorageProfile with the cloneStrategy key set to snapshot, but the LVM operator is set this value to copy by default. You will want to change this if/when using the LVM operator. The process is very simple, and will be covered below.

You will have one (1) StorageProfile for each StorageClass in your OpenShift cluster. You can view the StorageProfile objects with the following command. These objects are not namespaced, similar to StorageClass objects.

❯ oc get storageprofile
NAME                 AGE
lvms-vg1             6d5h
lvms-vg1-immediate   6d5h
nfs-openshift        6d2h

❯ oc get storageclass
NAME                           PROVISIONER      RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
lvms-vg1                       topolvm.io       Delete          WaitForFirstConsumer   true                   12d
lvms-vg1-immediate (default)   topolvm.io       Delete          Immediate              true                   12d
nfs-openshift                  nfs.csi.k8s.io   Delete          Immediate              false                  6d2h

You can view the YAML for the StorageProfile by using the following command (we will use lvms-vg1 as an example. Look for the spec, and

oc get storageprofile lvms-vg1-immediate -o yaml

It will likely look like the sample below. By default, you can see that the cloneStrategy is set to copy (look at the status section). We don't want this, and would prefer to set snapshot.

apiVersion: cdi.kubevirt.io/v1beta1
kind: StorageProfile
metadata:
  creationTimestamp: "2024-08-30T15:16:03Z"
  generation: 3
  labels:
    app: containerized-data-importer
    app.kubernetes.io/component: storage
    app.kubernetes.io/managed-by: cdi-controller
    app.kubernetes.io/part-of: hyperconverged-cluster
    app.kubernetes.io/version: 4.16.1
    cdi.kubevirt.io: ""
  name: lvms-vg1-immediate
  ownerReferences:
  - apiVersion: cdi.kubevirt.io/v1beta1
    blockOwnerDeletion: true
    controller: true
    kind: CDI
    name: cdi-kubevirt-hyperconverged
    uid: 2825a572-ca0c-4fa2-bf30-9f05b0100e92
  resourceVersion: "13429408"
  uid: 94530d4b-99f1-4616-add9-b078264a8c05
spec: {}
status:
  claimPropertySets:
  - accessModes:
    - ReadWriteOnce
    volumeMode: Block
  - accessModes:
    - ReadWriteOnce
    volumeMode: Filesystem
  cloneStrategy: copy
  dataImportCronSourceFormat: pvc
  provisioner: topolvm.io
  snapshotClass: lvms-vg1
  storageClass: lvms-vg1-immediate

If your StorageProfile looks like the one above (set to copy vs snapshot), then you can use the following patch command to change the cloneStrategy.

IMPORTANT: The following command will NOT work if you didn't first follow the instructions for installing the LVM StorageClass exactly like I suggested HERE
```
oc patch storageprofile lvms-vg1-immediate -p '{"spec":{"cloneStrategy": "snapshot"}}' --type=merge
```

Part III: Customization

TBD when required for other various articles.

Final Thoughts

That's really all there is to it; it's that simple to install!

Let me know if you have any thoughts or questions on either LinkedIn or Twitter/X.

Appendix A: Additional Reading