Storage class migration for VM backend storage

[Alice Frosi]

Hi everyone,

We are now able to migrate the storage of a VM using volume migration [1]. However, this feature only takes into account the volumes specified in the VM spec and not the backend storage.

Currently. it isn't possible to migrate a VM using a TPM while running to another storage class. I'd like to brainstorm ideas on how we could implement this. 

IMO, this cannot be covered by the volume migration and the update volume strategy since the backend volume isn't part of the VM spec. One possibility is to migrate the backend storage when:

1. The admin changes the backend volume storage class in the KubeVirt CR

2. The VM is migrated and then together with the migration we also copy the storage to a new PVC on a new storage class.

With this mechanism we could label all the VM using TPMs or the backend storage to be migrated and implement a new eviction mechanism. Please let me know your thoughts.

[1] https://kubevirt.io/user-guide/storage/volume_migration/

Many thanks,

Alice

[Alice Frosi]

Also created an issue in kubevirt:

https://github.com/kubevirt/kubevirt/issues/13698

[Alex Kalenyuk]

TBH I am not completely sure about

The admin changes the backend volume storage class in the KubeVirt CR

Since it kind of invalidates everything instead of taking baby steps towards the migration process.

What if we do something similar regarding backend state volumes as what k8s does [0] with projected volumes for API access?
This would involve us starting to reflect the backend state volume in VMs which we avoided previously,
but I think it's worth a discussion. Migrating it would then become more streamlined with the other volume types.

[0] https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume

--
You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/kubevirt-dev/CABBoX7MjDzdWcgvXi37NdV0Y-hLaNC%2Bx9Bhzg6j10bTpd%3DK4uQ%40mail.gmail.com.

[Alice Frosi]

On Wed, Jan 15, 2025 at 5:20 PM Alex Kalenyuk <akal...@redhat.com> wrote:

TBH I am not completely sure about

The admin changes the backend volume storage class in the KubeVirt CR

Since it kind of invalidates everything instead of taking baby steps towards the migration process.

Well, changing the backend storage class doesn necessarily mean that you need to start to migrate all VMs right away. But rather you now reconfigured the backend storage. In this way, KubeVirt can detect that there is a mismatch in the storage class currently used by the VM and reported in KubeVirt CR. In this way, during the migration it creates a new backend storage of the new storage class.

 

What if we do something similar regarding backend state volumes as what k8s does [0] with projected volumes for API access?
This would involve us starting to reflect the backend state volume in VMs which we avoided previously,
but I think it's worth a discussion. Migrating it would then become more streamlined with the other volume types.

[0] https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume

Not sure, I still think, the backend volume shouldn't be reflected in the VM. Especially because  the VM editable by the users and KubeVirt changes the claimname in the case of RWO PVC.