Installing the Veeam Plug-in 🔌 for KubeVirt and the KubeVirt Proxy, Step by Step

Part of a weekly series on protecting Red Hat OpenShift Virtualization with Veeam Backup & Replication.

📖 Before you continue: this post follows the previous one in the series, where I explain the architecture and the five components we install here. If you haven't read it yet, start there: Same console, same repositories, same jobs, different hypervisor: Veeam 13.1 meets OpenShift Virtualization

This post is about getting the pieces installed. If you're the backup admin, you'll care about the first half (the plug-in on the backup server). If you're the platform engineer, the second half (the proxy inside the cluster) is yours. In practice you'll probably do both on the same call, so I'm keeping them together.

The good news: it's two installs and a handful of commands. The less good news: a couple of details in the docs are easy to miss, and I'll point them out as we go.

The deployment in one paragraph

Per the deployment page, you have two options for the backup server: deploy a new one, or reuse an existing one as long as it meets the plug-in's system requirements. Then you install two things:

1. Veeam Plug-in for KubeVirt on the backup server.
2. Veeam KubeVirt Proxy in the OpenShift cluster you want to protect, one per cluster.

Once both are in place, you add the cluster to the Veeam console using the proxy's route and a token. That last step belongs to the next post.

Before you start: what has to be true

For the proxy install you also need a workstation with the OpenShift CLI 4.20 or later and Helm 4.1 or later. That's what the install page states, and I'd treat those as minimums.

If your storage doesn't give you block-mode PVCs with working CSI snapshots, stop here ✋🏻. Nothing else in this post will help you, and I'll dedicate a full post to that topic.

Step 1: Install the plug-in on the backup server

Two flavors, depending on what your backup server runs.

Windows-based backup server

1. Log in with an account that has local Administrator rights.
2. Download the installer for Windows-based backup servers from the Veeam download page, open the ZIP and run the .exe.
3. The installer checks for the Microsoft .NET Core Runtime. If it's missing, it offers to install it. Click OK.
4. Walk through the wizard: accept the license agreement, licensing policy and third-party agreements (you can't continue without accepting), optionally change the installation directory, and click Install.

🐧 Linux-based backup server

1. Download the installer for Linux-based backup servers from the Veeam download page.
2. Log in to the Host Management web console.
3. Go to Logs and Services > Components and click Add Component.
4. Upload the installation file, then click Install Now to acknowledge the agreements and start the installation.

A detail worth knowing

If you manage Veeam from a remote console, ⚠️ don't install the plug-in on the workstation where the console runs. It goes on the backup server only.

Step 2: Install the KubeVirt Proxy in the cluster

Run this from any machine that can reach the cluster API.

First, log in to the OpenShift server:

oc login --server="https://api.mycluster.example.com:6443" -u <user> -p <password>

The docs use user and password here, with an account that has admin permissions in the cluster. Personally I'd log in with a token or your usual SSO flow instead of typing a password into a shell, but that's my preference. The docs don't say anything about the minimum privileges needed beyond "administrative operations".

Add Veeam's chart repository:

helm repo add veeamrepo https://charts.veeam.com/
helm repo update

Install the proxy:

helm install vkp veeamrepo/vkp --namespace=<vkp_name> --set eula.accept=true --create-namespace

Two parameters are mandatory: --namespace and --set eula.accept=true. Without both, the installation won't proceed. If you want to see everything you can tune (logging level, for example), run helm show values against the chart.

Air-gapped clusters

If your cluster can't reach Veeam's chart repo or its image registry, the docs give you three parameters to point the installation at your own mirror:

• --set chartRepo for the Helm charts URL
• --set image.registry for the image registry
• --set image.Tag for the image tag

The docs don't walk through mirroring the images, so plan that part yourself.

Step 3: Tell the proxy which snapshot class to use

This one only applies if you have more than one VolumeSnapshotClass configured for the storage classes of the volumes you want to protect. In that case the proxy needs to know which to use, and you tell it with an annotation on the storage class:

oc annotate storageclass <storage_class> vkp.veeam.com/volume-snapshot-class=<volume_snapshot_class>

If you'd rather force every snapshot through one class regardless of the volume type, annotate the snapshot class instead:

oc annotate volumesnapshotclass <volume_snapshot_class> vkp.veeam.com/is-snapshot-class=true

On a cluster with a single storage backend (say ODF with one class) you may never need this. On clusters with several, skipping it is a good way to end up with snapshots taken through a class you didn't intend.

Step 4: Grab the connection details

You need two things to add the cluster to Veeam later: the proxy's route and its token.

oc get route -n vkp
oc get secret vkp-token -n vkp -o jsonpath='{.data.token}' | base64 -d

Here's the catch that trips people up. The install command uses --namespace=<vkp_name>, a namespace of your choosing, but these two commands use a hardcoded -n vkp. If you installed into a namespace with a different name, change it here too, or you'll get "not found" and wonder what went wrong.

Also treat that token like a credential, because it is one. It's what lets the backup server talk to the proxy. Don't paste it into a ticket or a chat.

What I'd check before you try this

• Cluster is on 4.20, 4.21 or 4.22, and you have at least one block-mode PVC with a snapshot-capable CSI driver.
• A VolumeSnapshotClass exists. If you have several, you know which one the proxy should use and you've annotated it.
• Backup server is on 13.1.x, and the plug-in and proxy versions match the compatibility table.
• The workstation running the install has oc 4.20+ and Helm 4.1+.
• You picked the proxy namespace on purpose, because you shouldn't delete it or edit what's inside later.
• For air-gapped sites, charts and images are already mirrored.
• You know where the route and token will be stored safely.

The docs also have pages for upgrading and uninstalling both components. I haven't covered them here because I haven't walked through them yet.

➡️ Next up: connecting the cluster to Veeam with the route and token you just retrieved.

🇦🇷 ¿Preferís leerlo en español? Esta misma guía está en mi blog: Instalar el plug-in y el proxy de Veeam para OpenShift Virtualization, paso a paso. Más sobre Veeam, Red Hat y OpenShift Virtualization en estebanprieto.home.blog.