This message was deleted.

the vms are using a storage class called " longhorn-image-tcl6v "

If you use YAML to configure, you can also set the default to 1 during deployment if you will only ever have 1 node. https://docs.harvesterhci.io/v1.2/install/harvester-configuration#installharvesterstorage_classreplica_count

I found out from https://docs.harvesterhci.io/v1.2/install/update-harvester-configuration. Seems that I can change Harvester's settings without having to install it again. I'm working with 4 harvester nodes, and I'm not sure if I need to change the settings in each nodes or not. I am going to test this out. This is for my home labs, so I want to use less disk space. It would also be good to have a way for user to choose the no of replicas when they need them. I used Longhorn for two things: for the storage of VM and, the PV of the RKE cluster that was provisioned on Harvester. I think choosing different storage classes might help, but I couldn't find much information on how this works from the offical docs.

You can't change the storage class via the /oem file. There is a replica count setting in the Longhorn UI, but I haven't tried changing that. We are only single-node and leave the default at 3 and create a new storage class with count 1 and use that for our VMs so their disks don't show as degraded. The way to do it is to create different classes with different replica counts.

I see. Seem not all config can be updated via the config file. Agree, I just figured out I need to create a storage class and use it for the 'image' and 'vm' data storage. Also, the no of replica for the 'vm' will inherent from the 'image.' In Longhorn UI, that no of replica depends on the storage class. Since the volumes are dynamically created, isn't a good place to set the replica. Additionally, the downstream RKE2 cluster will use the Harvester's default storage class to create PV. I couldn't find a way to change this setting yet.

I was actually wondering about something similar myself just the other day.. I wanted to pick the storage class for the cluster nodes in the deployment and use one I defined, but that option was apparently missing

you may create a storage class with a specific replica count and set it as the default storage class, afterwards, the image will inherit this setting.

that would work as a workaround, but I think that might not be workable in all scenarios so would probably be good to eventually add a storage class option to the interface 🙂