MTV-2419 | VM spec should be preserved if possible#4290
MTV-2419 | VM spec should be preserved if possible#4290gwencasey96 wants to merge 2 commits intokubev2v:mainfrom
Conversation
gwencasey96
requested review from
Hazanel,
mnecas,
mrnold,
solenoci and
yaacov
as code owners
|
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4290 +/- ##
=========================================
- Coverage 15.45% 8.28% -7.17%
=========================================
Files 112 461 +349
Lines 23377 52293 +28916
=========================================
+ Hits 3613 4333 +720
- Misses 19479 47578 +28099
- Partials 285 382 +97
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
I am trying to understand what this does. It looks like if you have a VM with a DataVolumeTemplate on one OpenShift cluster, and then migrate it to another cluster, the resulting VM spec will keep a copy of that DataVolumeTemplate. And this DataVolumeTemplate will create a DataVolume that adopts the existing destination PVC that forklift created during the migration? Do I have it right, or is there more to it than this? It seems simple enough but I am not clear on whether or not there are other side effects. Would the PVC namespace in the DataVolumeTemplate need to be adjusted for the destination migration namespace? |
| object.Template = targetVmSpec.Template | ||
| // Preserve DataVolumeTemplates from source VM to maintain user workflows | ||
| // that may expect the VM's DataVolume to be present | ||
| object.DataVolumeTemplates = targetVmSpec.DataVolumeTemplates |
There was a problem hiding this comment.
This preserves the spec, but what about the disks themselves referenced in the spec?
There was a problem hiding this comment.
thank you-there were a few things in my initial PR I needed to think through more. Now the DataVolumeTemplate names are mapped to the PVC names that Forklift uses when creating DataVolumes and sanitized. The volume references will also be updated when template names change
There was a problem hiding this comment.
The disk references are preserved in line above so we don't need anything else
object.Template = targetVmSpec.Template
but still question is: Are we migrating the datavolume referenced in the VM?
If you look at the export api which is used for the cold migraiton it support datavolumes. Are we using it already in a way that the datavolumes data are copied?
When migrating a VM from OCP to OCP, if the source VM had a dataVolumeTemplate, the target VM will now preserve it. Previously, the target VM only referenced the target PVC, but some user workflows may expect the VM's DataVolume to be present. This fix: 1. Updates the OCP builder to copy DataVolumeTemplates from the source VM spec 2. Updates vmTemplate to preserve DataVolumeTemplates when source is OCP Resolves: MTV-2419 Signed-off-by: Gwen Casey <gcasey@redhat.com>
…klift-created DataVolumes When preserving DataVolumeTemplates for OCP-to-OCP migrations, we need to: 1. Match template names to PVC names (Forklift creates DataVolumes with Name = pvc.Name) 2. Clear spec.source to prevent KubeVirt from trying to create new DataVolumes with invalid source URLs 3. Update volume references when DataVolumeTemplate names change This ensures that preserved DataVolumeTemplates correctly reference the DataVolumes that Forklift creates during migration, preventing conflicts and ensuring the VM can start successfully. Resolves: MTV-2419 Signed-off-by: Gwen Casey <gcasey@redhat.com>
gwencasey96
force-pushed
the
vm-spec-should-be-preserved-if-possibler
branch
from
33de0d9 to
d881d33
Compare
|
mnecas
left a comment
mnecas
left a comment
There was a problem hiding this comment.
I'm still not understanding some parts.
Mainly
| object.Template = targetVmSpec.Template | ||
| // Preserve DataVolumeTemplates from source VM to maintain user workflows | ||
| // that may expect the VM's DataVolume to be present | ||
| object.DataVolumeTemplates = targetVmSpec.DataVolumeTemplates |
There was a problem hiding this comment.
The disk references are preserved in line above so we don't need anything else
object.Template = targetVmSpec.Template
but still question is: Are we migrating the datavolume referenced in the VM?
If you look at the export api which is used for the cold migraiton it support datavolumes. Are we using it already in a way that the datavolumes data are copied?
| // 2. Clear spec.source to prevent KubeVirt from trying to create new DataVolumes with invalid sources | ||
| // 3. Ensure namespace is set correctly (will be set by KubeVirt to match VM namespace) | ||
| // 4. Update volume references to match renamed DataVolumeTemplates | ||
| r.sanitizeDataVolumeTemplates(vmRef, object.DataVolumeTemplates, object) |
There was a problem hiding this comment.
don't think we need this we are trying to persist the VM spec as much as possible to the source, my main question was about the disks themselves and the data on them
4 participants
MTV-2419 | VM spec should be preserved if possible
When migrating a VM from OCP to OCP, if the source VM had a dataVolumeTemplate, the target VM will now preserve it. Previously, the target VM only referenced the target PVC, but some user workflows may expect the VM's DataVolume to be present.
This fix:
Resolves: MTV-2419