This message was deleted.

It looks like re-creating the StorageClass with the “correct” name for the

backingImage

worked. The volume is currently restoring in Longhorn. This looks like a bug in the sync-up between existing backups (NFS in my case) and the new version of Longhorn

Hi @hundreds-easter-25520 Did you have any update on the backing image between VM backup and restore? Did the VM backup and restore happen on the same Harvester cluster or restore to another one? If you can provide the SB during the problem occurs, we can take a look at it. Thanks

The backup was from one harvester cluster, and the restore was to a fresh install of harvester 1.2.0 (on the same hardware). Further investigation of the issue has led me to find that there is a difference in the way the backingimage is created when used via the GUI and the API (terraform in my case). See https://github.com/harvester/harvester/issues/4520. It looks like something in the front end is detecting the “long” name and taking care of it, but it isn’t happening when done through the API. I’m still investigating cases and causes.

https://github.com/longhorn/longhorn-manager/blob/432b6d40f02a6fdffd8389df9d779016775f1d3a/webhook/resources/backingimage/mutator.go#L50 Longhorn webhook has a name length limitation of 40 characters long for backing images. If it exceeds the limitation, it will automatically change the backing image name. If you create a VMImage from Harvester GUI, since Harvester names the backing image internally, it would not be longer than 40 characters long. But if you create a VMImage with terrafrom, the backinge image name has the chance to be truncated and decoupled with the storage class name. If you use terraform, please make sure

<VMImage namsespace>-<VMImage Name>

is less than 40 characters long. Thanks.