Taking Point‑in‑Time Snapshots of VMs in Harvester Without Downtime

Why snapshots matter for running workloads

When a virtual machine hosts a database, CI agent, or any service that cannot be stopped, administrators need a way to capture its disk state at a specific moment. Harvester provides this capability by integrating KubeVirt with Longhorn, allowing you to create a snapshot while the VM stays powered on.

How the feature works under the hood

Harvester automatically installs the VolumeSnapshotClass and VolumeSnapshot CRDs when the cluster is provisioned. A snapshot request triggers Longhorn to create a read‑only snapshot of the underlying volume, which is then represented as a VolumeSnapshot custom resource in the kube-system namespace. The VM continues to write to its original volume; only the changed blocks are stored in the snapshot, keeping space usage proportional to the delta.

Worked example: creating and verifying a snapshot via CLI

1. Prerequisites: You need harvesterctl installed and a context pointing to a Harvester cluster (v1.1+). You must have the harvester:vm-admin role or equivalent RBAC permissions.
2. Create a VM (if you don’t already have one):

   harvesterctl vm create \
         --name demo-vm \
         --image harvester/harvester-node:latest \
         --cpu 2 --memory 4Gi \
         --volume size=20Gi,storageClass=longhorn
   

3. Take a snapshot while the VM is running:

   harvesterctl vm snapshot demo-vm \
         --name pre-upgrade-snap \
         --description "Snapshot before applying OS patches"
       

   This command returns immediately; the snapshot operation runs asynchronously.
4. Verify the snapshot:
   • Check that a VolumeSnapshot object appears:

     kubectl get volumesnapshot -n kube-system pre-upgrade-snap -o yaml
     

     Look for readyToUse: true in the status.
   • In the Longhorn UI (accessible via http://<harvester‑ip>:8000), navigate to Volumes → find the volume bound to demo-vm → Snapshots tab. You should see a snapshot named pre-upgrade-snap with a size equal to the data changed since the VM’s creation.
5. Restore to a new VM (optional):

   harvesterctl vm create \
         --name demo-vm-restored \
         --from-snapshot pre-upgrade-snap \
         --cpu 2 --memory 4Gi \
         --volume size=20Gi,storageClass=longhorn
   

   Boot the new VM and confirm that its filesystem matches the state at snapshot time.

Trade‑offs and practical limits

Each snapshot stores only the blocks that have changed since the previous snapshot, but for write‑intensive workloads (e.g., heavy logging or database transaction logs) the delta can grow quickly, consuming storage comparable to a full copy. Moreover, restoring a snapshot overwrites the current disk; any data written after the snapshot point is lost unless you have an external backup. To mitigate growth, schedule snapshots during low‑activity windows or implement a retention policy that deletes older snapshots after a defined period.

Actionable steps for your environment

• Enable the VolumeSnapshotClass in your Harvester deployment (it is installed by default; verify with kubectl get volumesnapshotclass).
• Define a snapshot schedule using a CronJob that calls harvesterctl vm snapshot for critical VMs.
• Monitor snapshot storage usage via Longhorn’s UI or the longhorn-volume-snapshot Prometheus metric.
• Test restore procedures on a non‑production cluster to ensure your backup‑and‑recovery workflow meets RTO/RPO requirements.