You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
KubeVirt Virtual Machines have a very similar spec as pods/deployments/etc. Being able to treat them as first class citizens when doing a DirectVolumeMigration will allows us to easily migrate storage used for these VMs.
Describe the solution you'd like
Besides all the normal pod owner detection (deployments/daemonsets/replicasets/jobs/etc) also detect Virtual Machines during the discovery phase of the DirectVolumeMigration. Then list the VMs in the UI as options for migration. Then when staging the DirectVolumeMigration, copy the volumes in the same way as the other sources. When cutting over switch the volumes in the VM specification to the new volumes, same way as happens in other sources (see additional context for live storage migration).
Describe alternatives you've considered
Since conceptually VMs are very similar to deployments it makes sense to make VMs first class citizens in the DirectVolumeMigration flow.
Additional context
KubeVirt is currently working on StorageLiveMigration where a running VM can switch volumes without having to shut down. This can be integrated with the current DirectVolumeMigration process as well. Instead of shutting down the VM and finalizing the migration, we can do the migration while the VM stays running.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
KubeVirt Virtual Machines have a very similar spec as pods/deployments/etc. Being able to treat them as first class citizens when doing a DirectVolumeMigration will allows us to easily migrate storage used for these VMs.
Describe the solution you'd like
Besides all the normal pod owner detection (deployments/daemonsets/replicasets/jobs/etc) also detect Virtual Machines during the discovery phase of the DirectVolumeMigration. Then list the VMs in the UI as options for migration. Then when staging the DirectVolumeMigration, copy the volumes in the same way as the other sources. When cutting over switch the volumes in the VM specification to the new volumes, same way as happens in other sources (see additional context for live storage migration).
Describe alternatives you've considered
Since conceptually VMs are very similar to deployments it makes sense to make VMs first class citizens in the DirectVolumeMigration flow.
Additional context
KubeVirt is currently working on StorageLiveMigration where a running VM can switch volumes without having to shut down. This can be integrated with the current DirectVolumeMigration process as well. Instead of shutting down the VM and finalizing the migration, we can do the migration while the VM stays running.
The text was updated successfully, but these errors were encountered: