-
Feature
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
-
Product / Portfolio Work
-
False
-
-
False
-
Not Selected
-
Feature Overview
Migrate VMs between clusters that share the same storage array without copying the bulk of the VM disk data.
Goals
Current CCLM transfer TiB of disk data over the network, even if both a clusters share the same storage. This makes CCLM slow, fragile, and causing storage duplication on the array.
This feature would utilize storage provider-specific APIs (a-la XCOPY) to offload most of the data transfer to the storage array, similar to what MTV is doing.
Requirements
| Requirement | Notes | isMvp? |
|---|---|---|
| CCLM with storage offload for a single storage provider | Yes | |
| Ecosystem parity with MTV | Every provider that we support when importing VMs, should be supported when we move VMs between clusters | |
(Optional) Use Cases
How will the user interact with this feature?
Any user of CCLM should seamlessly use this feature if both clusters share the same storage array.
Which users will use this and when will they use it?
- As an admin of two clusters backed by the same storage array, I would like to move VMs from one cluster to another in preparation for a downtime or in response to a sudden growth of compute demands.
Background, and strategic fit
Assumptions
- Engineering constraint: the code can be reused by MTV, but should not depend on it. CCLM should work without MTV installed in the cluster.
Customer Considerations
- We need to choose which storage provider should we first support. This depends on technical ease of implementation, partner relationship, and of course - customer needs.
Documentation Considerations
CCLM documentation https://docs.okd.io/4.20/virt/live_migration/virt-enabling-cclm-for-vms.html should barely change by this feature. It should only mention the storage arrays that support the storage offload optimization.
User Experience Considerations
When both cluster use the same storage array that is supported for storage offload, there should be an indication celebrating this, eg "Storage offload used during migration". There should be no other change to UXD, apart from the fact the migration takes less time on clusters that properly support it. One thing