Backing Image
Longhorn natively supports backing images since v1.1.1.
A QCOW2 or RAW image can be set as the backing/base image of a Longhorn volume, which allows Longhorn to be integrated with a VM like Harvester.
There are 3 kinds of data sources. Or in other words, there are 3 ways to prepare a backing image file data:
shasum -a 512 <the file path>
regardless of the file format.On Setting > Backing Image page, users can create backing images with any kinds of data source.
You can download a file or export an existing volume as a backing image via YAML. It’s better not to “upload” a file via YAML. Otherwise, you need to manually handle the data upload via HTTP requests.
Here are some examples:
apiVersion: longhorn.io/v1beta2
kind: BackingImage
metadata:
name: bi-download
namespace: longhorn-system
spec:
sourceType: download
sourceParameters:
url: https://longhorn-backing-image.s3-us-west-1.amazonaws.com/parrot.raw
checksum: 304f3ed30ca6878e9056ee6f1b02b328239f0d0c2c1272840998212f9734b196371560b3b939037e4f4c2884ce457c2cbc9f0621f4f5d1ca983983c8cdf8cd9a
apiVersion: longhorn.io/v1beta2
kind: BackingImage
metadata:
name: bi-export
namespace: longhorn-system
spec:
sourceType: export-from-volume
sourceParameters:
volume-name: vol-export-src
export-type: qcow2
In a Longhorn StorageClass.
Setting parameter backingImageName
means asking Longhorn to use this backing image during volume creation.
If you want to create the backing image as long as it does not exist during the CSI volume creation, parameters backingImageDataSourceType
and backingImageDataSourceParameters
should be set as well. Similar to YAML, it’s better not to create a backing image via “upload” in StorageClass. Note that if all of these parameters are set and the backing image already exists, Longhorn will validate if the parameters matches the existing one before using it.
download
:kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: longhorn-backing-image-example
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
numberOfReplicas: "3"
staleReplicaTimeout: "2880"
backingImage: "bi-download"
backingImageDataSourceType: "download"
backingImageDataSourceParameters: '{"url": "https://backing-image-example.s3-region.amazonaws.com/test-backing-image"}'
backingImageChecksum: "SHA512 checksum of the backing image"
export-from-volume
:kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: longhorn-backing-image-example
provisioner: driver.longhorn.io
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
parameters:
numberOfReplicas: "3"
staleReplicaTimeout: "2880"
backingImage: "bi-export-from-volume"
backingImageDataSourceType: "export-from-volume"
backingImageDataSourceParameters: '{"volume-name": "vol-export-src", "export-type": "qcow2"}'
Create a PVC with the StorageClass. Then the backing image will be created (with the Longhorn volume) if it does not exist.
Longhorn starts to prepare the backing images to disks for the replicas when a volume using the backing image is attached to a node.
\
when you input a download URL in a StorageClass.Users can directly create then immediately use a backing image via StorageClass, or utilize an existing backing image as mentioned below.
Backup
and pick up a backup volume for the restore.Since v1.3.0, users can download existing backing image files to the local via UI.
Backing Image Cleanup Wait Interval
. But Longhorn will retain at least one file in a disk for each backing image anyway.unknown
. Later on if the node is back and the pod is running, Longhorn will detect then reuse the existing files automatically.© 2019-2024 Longhorn Authors | Documentation Distributed under CC-BY-4.0
© 2024 The Linux Foundation. All rights reserved. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see our Trademark Usage page.