Is your feature request related to a problem? Please describe.
Currently it is impossible to DirectVolumeMigrate block volumes as all direct volume migration uses rsync to synchronize the volumes. It would be nice if we could direct volume migrate block volumes. This is especially important if you want to migrate KubeVirt Virtual Machine disks as the recommendation is to use block volumes for those.
Describe the solution you'd like
The ability to successfully DirectVolumeMigrate block volumes.
Describe alternatives you've considered
When a block volume is detected instead of failed, use something like diskrsync or a modified kopia block backup to do the synchronization.
Additional context
It would be nicer if there was Change Block Tracking in kubernetes that we could use, however the alternatives above should provide a CBT mechanism that is sufficient for our needs.
A side note on Virtual Machine disks that are on a filesystem. Since KubeVirt creates a single large disk image file on the filesystem, it is essentially the same as a block device. rsync doesn't really know how to handle this, and if there is a change in the source, it will synchronize the entire file even if only a few bytes changed. So it might make sense to have a special case for single large image files and treat them as block volumes.
### Tasks
- [ ] The available copy methods currently are ‘filesystem’ and ‘snapshot’. In order to allow block volumes, add a new copy method called ‘block’.
- [ ] Besides access mode in the PVC struct, we also need volume mode now, to indicate the volume is a block volume or filesystem volume.
- [ ] When creating the migration job, we need to use the information from the PVC to create volumeDevices and volumeMounts, instead of just volumeMounts based on the volume mode.
- [ ] During the validation phase take the new volume mode into consideration.
- [ ] When creating the migration job, instead of calling rsync, call the block migration application to do the heavy lifting. This should report progress in the same manner as the rsync based copy does.
Is your feature request related to a problem? Please describe. Currently it is impossible to DirectVolumeMigrate block volumes as all direct volume migration uses rsync to synchronize the volumes. It would be nice if we could direct volume migrate block volumes. This is especially important if you want to migrate KubeVirt Virtual Machine disks as the recommendation is to use block volumes for those.
Describe the solution you'd like The ability to successfully DirectVolumeMigrate block volumes.
Describe alternatives you've considered When a block volume is detected instead of failed, use something like diskrsync or a modified kopia block backup to do the synchronization.
Additional context It would be nicer if there was Change Block Tracking in kubernetes that we could use, however the alternatives above should provide a CBT mechanism that is sufficient for our needs.
A side note on Virtual Machine disks that are on a filesystem. Since KubeVirt creates a single large disk image file on the filesystem, it is essentially the same as a block device. rsync doesn't really know how to handle this, and if there is a change in the source, it will synchronize the entire file even if only a few bytes changed. So it might make sense to have a special case for single large image files and treat them as block volumes.