ovirt: Respect storage mapping #822
Conversation
|
@bennyz we have the same issue with OpenStack, could you please post a fix for that as well? |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #822 +/- ##
=========================================
+ Coverage 0 16.86% +16.86%
=========================================
Files 0 93 +93
Lines 0 19402 +19402
=========================================
+ Hits 0 3272 +3272
- Misses 0 15865 +15865
- Partials 0 265 +265
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
it looks (somewhat) fine, the next lines override the SC based on the volume type |
ok, so we don't use the first storage class that we find in the mapping for all the volumes but why do we use it at all? |
|
filed #823 for OpenStack, it's indeed a bit different and less important than the issue this fix is intended for |
Previously, when migrating to the cluster Forklift is deployed on using a cold migration, all disks of the migrated VM were transferred to the same storage class, which is one of the target storage class that appear in the storage mapping that is set for the migration plan. With these changes, each disk will be mapped to a target storage class based on its original storage domain and the storage mapping that is defined for the migration plan. Signed-off-by: Arik Hadas <[email protected]>
|
Previously, when migrating to the cluster Forklift is deployed on using a cold migration, all disks of the migrated VM were transferred to the same storage class, which is one of the target storage class that appear in the storage mapping that is set for the migration plan.
With these changes, each disk will be mapped to a target storage class based on its original storage domain and the storage mapping that is defined for the migration plan.