# harvester


03/23/2023, 1:26 AM
I expected to see the Longhorn storage classes I created in Harvester available in the K3s cluster I created in Rancher, but only the default class
appears. There must be another step. I see this in StorageClass doc:
Different Longhorn StorageClasses might map to replica policies, or to node schedule policies, or disk schedule policies determined by the cluster administrators
Now I see that I may select the Harvester storage class when creating an image, and may select the image for the nodes when creating a cluster. I see now how the Harvester storage class maps to the node's storage, but what about making Harvester storage classes available in the cluster for PVCs?


03/23/2023, 5:42 AM


03/24/2023, 10:00 PM
Skimming a lot of information here. It sounds like the same goal: use Harvester-defined storage classes with the guest cluster's PVCs. Is the current solution applicable only to RKE2 with Harvester as the cloud provider, perhaps?
I am able to select the Harvester cloud provider if I opt-in to deprecated K8s versions and pick 1.24.9+rke2r2 (deprecated). Choosing the same version shown in Mike Russell's screenshot, 1.24.10+rke2r1, this alert appears in the UI:
You cannot select the Harvester cloud provider as the current Harvester version is not compatible with the selected RKE2 Kubernetes version, click here to see which Kubernetes versions are supported.
I am using Rancher 2.7.1 with Harvester 1.1.1.
Thank you for sharing the GH issue about storage tiering. That was a helpful read. If I understood correctly, I should be able to use storage tiering by creating a conformant StorageClass resource in the guest cluster by providing additional manifests when creating the cluster in Rancher. If so, the only remaining problem is to identify a compatible matrix of Rancher, Harvester, and RKE2 versions. I learned from the SUSE support matrix site linked above that I can use Harvester 1.1.1 with Rancher 2.6.9. With those versions the newest RKE2 cluster I can create is v1.22.17+rke2r1. That is older than expected. There appears to be a workaround to change the allowed RKE2 versions for creating clusters in Rancher with Harvester cloud provider, but I don't have enough context to estimate the risk or wisdom of doing that. Is there a better matrix of Rancher, Harvester, and RKE2 versions I can try?
I found that matrix of versions with a guest cluster pvc with default storage class produced a Harvester volume with storage class "longhorn," which is not the default class in Harvester. Additionally, after releasing those guest PVCs, I declared one of the custom SCs I created along with the guest cluster, example below. Still, the PV has the "longhorn" storage class. In this example,
is a valid Harvester SC that I expected to use through the CSI in a guest cluster PVC.
Copy code
apiVersion: <|>
kind: StorageClass
  name: singleton-nvme
provisioner: <|>
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: Immediate
  hostStorageClass: singleton-nvme
I obtained the same result with RKE2 v1.24.9+rke2r2. It was necessary to opt-in to deprecated versions of RKE2 in Rancher to pick this version. Next I will try stepping forward Rancher from v2.6.9, the version prescribed in the SUSE compatibility matrix.
Storage tiering works in v1.24.11+rke2r1, the default version in Rancher 2.6.11 for Harvester cloud provider.