Feature Overview (mandatory - Complete while in New status)
Enable administrators to migrate VMware VMs to OpenStack with minimal downtime by performing incremental disk seeding across multiple maintenance windows, followed by a final cutover with one last delta sync.
Large enterprise VMs with terabytes of data cannot be migrated in a single maintenance window. This feature exposes the existing CBT (Changed Block Tracking) and cutover capabilities as a user-friendly, multi-phase migration workflow. Users can "seed" VM disk data incrementally during multiple low-impact windows while the source VM remains running, then execute a final cutover with minimal downtime, typically only the time needed to sync the last changed blocks and perform V2V conversion.

Goals (mandatory - Complete while in New status)

• Cloud Administrators: Can migrate large VMs across multiple maintenance windows without extended downtime

• Operations Teams: Flexibility to perform incremental syncs during off-peak hours, reserving brief cutover window for production transition
• End Users/Tenants: Minimal service disruption—source VM remains running during seeding phases

Requirements (mandatory -_ Complete while in Refinement status):

Done - Acceptance Criteria (mandatory - Complete while in Refinement status):
AC1: User can run migration with cbtsync: true and cutover: false to perform incremental disk synchronization without V2V conversion
AC2: CBT changeID is persisted in Cinder volume metadata after sync operations
AC3: User can run migration with cutover: true to perform final delta sync and V2V conversion
AC4: If volume already exists and cbtsync: false, migration returns error "volume already exists"
AC5: If volume already converted (converted: true metadata), migration skips with message "Volume already converted"
AC6: Windows VMs are only powered off when runV2V=true (i.e., during cutover)
AC7: Ansible role import_workloads exposes import_workloads_cutover and import_workloads_cbt_sync variables

Use Cases - i.e. User Experience & Workflow: (Initial completion while in Refinement status):
Implemented Workflow: Two-Phase CBT Migration
Phase 1 (or multiple) - Initial/Incremental Sync (repeatable):

# Performs disk copy using CBT, skips V2V conversion
# Source VM remains running
cbt_sync: true
cutover: false

Final Phase  - Final Cutover:

# Performs final sync and V2V conversion
# Windows VMs will be powered off for conversion
cbt_sync: true  # or false for no delta sync
cutover: true

Out of Scope __(Initial completion while in Refinement status):
High-level list of items or persona’s that are out of scope.
<your text here>

Documentation Considerations __(Initial completion while in Refinement status):
Provide information that needs to be considered and planned so that documentation will meet customer needs. If the feature extends existing functionality, provide a link to its current documentation..
<your text here>

Questions to Answer __(Initial completion while in Refinement status):
Include a list of refinement / architectural questions that may need to be answered before coding can begin.
<your text here>

Background and Strategic Fit (Initial completion while in Refinement status):

• Leverages VMware's native Changed Block Tracking (CBT) for efficient delta synchronization

• Implements industry-standard pattern for live migration with minimal downtime

• Built on proven nbdkit/VDDK integration for reliable disk transfer

• Supports enterprise requirements for controlled migration windows

Customer Considerations __(Initial completion while in Refinement status):

• VMware CBT requirement: Source VMs must have CBT enabled before migration

• Volume storage costs: Seeded volumes consume OpenStack storage during sync phases before cutover

• Windows VM handling: Windows VMs will be powered off during cutover phase for V2V conversion

• Sync frequency: More frequent sync phases = smaller final delta = shorter cutover window

Team Sign Off (Completion while in Planning status)

• All required Epics (known at the time) are linked to the this Feature
• All required Stories, Tasks (known at the time) for the most immediate Epics have been created and estimated
• Add - Reviewers name, Team Name
• Acceptance == Feature as “Ready” - well understood and scope is clear - Acceptance Criteria (scope) is elaborated, well defined, and understood
• Note: Only set FixVersion/s: on a Feature if the delivery team agrees they have the capacity and have committed that capability for that milestone

• …