Chapter 4: Migration Types and Strategy Selection
Understanding migration types is crucial for selecting the appropriate strategy based on your downtime requirements, complexity tolerance, and source platform capabilities. This chapter provides comprehensive details about each migration approach to help you make informed decisions for your specific use cases.
Overview: Migration Strategy Fundamentals
Migration strategy selection impacts:
- Service Availability: How long applications remain offline
- Operational Complexity: Level of technical coordination required
- Resource Requirements: Infrastructure needed during migration
- Risk Profile: Potential failure points and recovery procedures
- Performance: Total migration time and resource utilization
Cold Migration
Cold migration is the traditional and most straightforward migration approach, offering simplicity and reliability at the cost of extended downtime.
Process Overview
- Complete Shutdown: Source VM is powered down completely during the entire migration process
- Offline Transfer: All disk data is transferred while the VM is offline
- Single-Stage Process: One continuous operation from start to completion
- State Preservation: VM configuration and data integrity maintained throughout
Characteristics
| Aspect | Details |
|---|---|
| Downtime | Hours (complete service interruption) |
| Complexity | Low (single-stage process) |
| Reliability | Highest (fewest variables) |
| Resource Usage | Predictable and consistent |
| Platform Support | All supported source platforms |
Advantages
- Simplicity: Single-stage process with minimal complexity
- Reliability: Most predictable approach with fewer failure points
- Data Consistency: No concerns about data changes during transfer
- Universal Compatibility: Works with all supported source platforms
- Predictable Timeline: Linear progression with estimable completion times
- Lower Resource Requirements: No need for change tracking or delta synchronization
- Easier Troubleshooting: Straightforward process with clear failure points
Disadvantages
- Extended Downtime: Longest service interruption of all migration types
- Business Impact: Complete service unavailability during migration
- User Experience: Total application inaccessibility
- Revenue Impact: Potential loss during extended offline periods
- SLA Challenges: May violate availability service level agreements
Use Cases and Scenarios
Ideal Situations for Cold Migration
Non-Critical Systems:
- Development and test environments
- Internal tools and utilities
- Backup and archival systems
- Systems with flexible availability requirements
Maintenance Windows:
- Planned outages during off-hours
- Systems with scheduled maintenance windows
- Applications with natural downtime periods
- Coordinated infrastructure updates
Complexity Avoidance:
- First-time migrations for validation
- Systems with unknown change patterns
- Complex configurations requiring offline analysis
- Risk-averse migration approaches
Technical Requirements:
- Source systems without live migration support
- Applications requiring clean shutdown procedures
- Systems with complex interdependencies
- Scenarios prioritizing simplicity over uptime
Cold Migration Process
- Pre-Migration Validation
- Verify source VM health and configuration
- Confirm target resource availability
- Validate network and storage mappings
- Schedule maintenance window
- Migration Execution
- Gracefully shutdown source VM
- Begin disk data transfer to target storage
- Monitor transfer progress and performance
- Validate data integrity during transfer
- Post-Migration Activation
- Complete final data validation
- Configure target VM settings
- Start target VM in destination environment
- Verify application functionality
- Cutover and Validation
- Update DNS and network configurations
- Test application accessibility
- Confirm service restoration
- Document migration completion
Warm Migration
Warm migration provides a balanced approach between downtime and complexity, making it the preferred choice for most production environments requiring minimal service interruption.
Process Overview
Warm migration operates in two distinct stages:
- Precopy Stage: Bulk data transfer while source VM continues operating
- Cutover Stage: Brief final synchronization with minimal downtime
- Change Tracking: Continuous monitoring of data changes during precopy
- Automated Coordination: System-managed stage transitions and timing
Migration Stages Detailed
Precopy Stage
The precopy stage handles the majority of data transfer while maintaining service availability:
Process:
- Source VM continues running normally
- Bulk disk data transferred to target storage
- Changes tracked for later synchronization
- Multiple iterations possible for highly active VMs
Duration Factors:
- Total disk size and data volume
- Network bandwidth and performance
- Source VM activity and change rate
- Storage performance on both sides
Monitoring:
- Transfer progress and completion percentage
- Change rate and delta accumulation
- Network utilization and bottlenecks
- Storage performance and throughput
Cutover Stage
The cutover stage completes the migration with minimal service disruption:
Process:
- Source VM is temporarily stopped
- Final delta changes synchronized
- Target VM configuration finalized
- Target VM started and validated
- Network and DNS cutover executed
Typical Timeline:
- Preparation: 30 seconds - 2 minutes
- Final Sync: 1-5 minutes (depending on delta size)
- VM Startup: 1-3 minutes
- Service Validation: 1-2 minutes
- Total Cutover: 2-10 minutes typical
Characteristics
| Aspect | Details |
|---|---|
| Downtime | Minutes (cutover period only) |
| Complexity | Medium (two-stage coordination) |
| Total Duration | Longer than cold (due to precopy iterations) |
| Service Impact | Minimal (brief interruption only) |
| Platform Support | All supported source platforms |
Advantages
- Minimized Downtime: Downtime reduced to cutover period only
- Business Continuity: Service remains available during bulk transfer
- Production Suitable: Appropriate for most business-critical applications
- Automated Management: System handles stage coordination automatically
- Scalable Approach: Works effectively for large VMs and datasets
- Flexible Timing: Cutover can be scheduled for optimal business windows
- Reduced Risk: Ability to validate precopy before committing to cutover
Disadvantages
- Increased Complexity: Two-stage process requires coordination
- Longer Total Time: May take longer overall than cold migration
- Change Rate Sensitivity: High-activity VMs may require multiple precopy iterations
- Resource Overhead: Requires additional resources for change tracking
- Timing Coordination: Cutover window requires careful scheduling
- Potential Delays: Heavy VM activity can delay cutover readiness
Use Cases and Scenarios
Production Systems
Business-Critical Applications:
- Customer-facing web applications
- Database systems with availability requirements
- E-commerce platforms and transaction systems
- Communication and collaboration tools
Large VM Migrations:
- VMs with substantial disk storage (>100GB)
- Database servers with large datasets
- File servers and content repositories
- Application servers with significant state
Availability Requirements:
- Systems with strict SLA requirements
- 24/7 operational systems
- Applications serving global user bases
- Revenue-generating services
Enterprise Scenarios:
- Data center consolidation projects
- Cloud migration initiatives
- Platform modernization efforts
- Disaster recovery implementations
Warm Migration Optimization
Minimizing Cutover Time
Precopy Optimization:
- Schedule precopy during low-activity periods
- Monitor change rates and plan accordingly
- Use multiple precopy iterations for very active VMs
- Optimize network and storage performance
Change Rate Management:
- Identify and temporarily pause non-essential processes
- Schedule migrations during natural low-activity periods
- Consider application-specific quiescing procedures
- Monitor and predict optimal cutover timing
Resource Allocation:
- Ensure adequate network bandwidth for final sync
- Optimize storage performance on target systems
- Allocate sufficient compute resources for VM startup
- Pre-position network and DNS configuration changes
Live Migration
Live migration offers the most advanced migration capability with minimal service disruption, leveraging KubeVirt’s sophisticated virtualization features for seamless workload mobility.
Process Overview
Live migration maintains continuous service operation through:
- Memory State Synchronization: Active memory continuously transferred
- Network Preservation: Existing connections maintained throughout migration
- State Continuity: Application state preserved during migration
- Minimal Interruption: Seconds-level service disruption maximum
Platform Requirements
Source Platform Limitations
Supported Sources:
- KubeVirt/OpenShift Virtualization clusters only
- Source must support live migration features
- Compatible virtualization infrastructure required
Unsupported Sources:
- VMware vSphere (use warm migration instead)
- oVirt/Red Hat Virtualization (use warm migration instead)
- OpenStack (use warm migration instead)
- OVA files (static format, requires warm/cold migration)
Technical Prerequisites
Network Requirements:
- High-bandwidth connectivity between clusters
- Low-latency network paths for memory synchronization
- Compatible network configurations and policies
- Shared or compatible storage accessibility
Storage Requirements:
- Shared storage accessible from both clusters, OR
- Compatible storage classes and provisioners
- Sufficient performance for real-time synchronization
- Consistent access policies and permissions
Live Migration Process
Memory and State Management
Continuous Synchronization:
- Active memory pages transferred iteratively
- Dirty page tracking and incremental updates
- Network connection state preservation
- Application session continuity maintenance
Final Switchover:
- Brief pause for final memory state transfer
- Network routing updates and connection preservation
- Storage handle transfers and access updates
- Service endpoint updates and validation
Network and Storage Coordination
Network Preservation:
- IP address continuity (where supported)
- Connection state maintenance
- Load balancer and service discovery updates
- DNS and routing table coordination
Storage Management:
- Persistent volume access transfers
- Storage handle and permission updates
- Data consistency validation
- Access pattern preservation
Characteristics
| Aspect | Details |
|---|---|
| Downtime | Seconds to low minutes |
| Complexity | High (advanced orchestration) |
| Platform Support | KubeVirt sources only |
| Service Impact | Minimal (near-transparent) |
| Technical Requirements | Significant infrastructure prerequisites |
Advantages
- Near-Zero Downtime: Service disruption measured in seconds
- Connection Preservation: Active sessions maintained throughout migration
- State Continuity: Application state preserved completely
- User Experience: Transparent migration from user perspective
- High Availability: Supports continuous operation requirements
- Advanced Technology: Leverages sophisticated KubeVirt capabilities
- Automated Recovery: Built-in failback and error recovery mechanisms
Disadvantages
- Platform Limitations: Restricted to KubeVirt source environments only
- Infrastructure Requirements: Significant network and storage prerequisites
- Complexity: Most complex migration approach with multiple coordination points
- Compatibility Constraints: Strict requirements for network and storage compatibility
- Resource Intensive: High network and compute resources during migration
- Limited Applicability: Narrow use case scope due to platform restrictions
Use Cases and Scenarios
Mission-Critical Applications
Zero-Downtime Requirements:
- Financial trading systems and real-time processing
- Healthcare systems with patient safety implications
- Emergency response and public safety systems
- High-frequency transaction processing systems
KubeVirt Platform Scenarios:
- Cluster consolidation within KubeVirt environments
- Hardware maintenance requiring VM mobility
- Load balancing and resource optimization
- Disaster recovery within Kubernetes infrastructure
Cloud-Native Migration:
- Modernization within Kubernetes ecosystems
- Multi-cluster application distribution
- Edge computing workload mobility
- Hybrid cloud optimization scenarios
Conversion Migration
Conversion migration is a specialized migration type for integration with external storage vendors and custom migration workflows. For comprehensive coverage of conversion migration including architecture, prerequisites, workflow, and troubleshooting, see Chapter 3.6: Conversion Migration.
Migration Strategy Decision Framework
Selection Criteria Matrix
Choose your migration approach based on these key factors:
| Criteria | Cold Migration | Warm Migration | Live Migration | Conversion Migration |
|---|---|---|---|---|
| Maximum Downtime Tolerance | Hours | Minutes | Seconds | Vendor-Dependent |
| Operational Complexity | Low | Medium | High | High |
| Source Platform Flexibility | All | All | KubeVirt Only | VMware Only |
| Infrastructure Requirements | Minimal | Standard | Advanced | Vendor Integration |
| Business Criticality | Low-Medium | Medium-High | Critical | Variable |
| Technical Resources | Basic | Intermediate | Advanced | Advanced + Vendor |
Decision Tree
- Platform Assessment
- Is source platform KubeVirt? –> Consider Live Migration
- Is source platform VMware with storage vendor integration? –> Consider Conversion Migration
- Other platforms (vSphere, oVirt, OpenStack, OVA) –> Cold or Warm Migration
- Integration Requirements
- Do you have compatible storage vendor solutions? –> Consider Conversion Migration (VMware only)
- Need standard Forklift-managed migration? –> Proceed to downtime assessment
- Downtime Requirements
- Can tolerate hours of downtime? –> Cold Migration
- Need minimal downtime (minutes)? –> Warm Migration
- Require near-zero downtime (seconds)? –> Live Migration (KubeVirt only)
- Complexity Tolerance
- Prefer simple, predictable process? –> Cold Migration
- Accept moderate complexity for reduced downtime? –> Warm Migration
- Have advanced technical capabilities? –> Live Migration
- Business Impact Assessment
- Non-critical systems? –> Cold Migration
- Production systems with flexibility? –> Warm Migration
- Mission-critical, zero-tolerance systems? –> Live Migration
Hybrid Approaches
Mixed Strategy Deployments
Environment-Based Selection:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# Development and test environments - Cold migration
kubectl mtv create plan dev-migration \
--migration-type cold \
--vms "dev-web-01,test-db-01"
# Production applications - Warm migration
kubectl mtv create plan prod-migration \
--migration-type warm \
--vms "prod-web-01,prod-api-01" \
--cutover "$(date -d 'Sunday 2:00 AM' --iso-8601=seconds)"
# Critical KubeVirt systems - Live migration
kubectl mtv create plan critical-k8s-migration \
--migration-type live \
--vms "trading-engine,payment-processor"
# Storage vendor integration - Conversion migration (VMware only)
# Note: PVCs must be pre-created by storage vendor
kubectl mtv create plan vendor-conversion \
--migration-type conversion \
--vms "vendor-provided-vm-01,vendor-provided-vm-02"
Risk-Based Progression:
- Phase 1: Cold migration for non-critical systems (validation)
- Phase 2: Warm migration for production workloads (standard approach)
- Phase 3: Live migration for mission-critical KubeVirt systems (advanced)
Performance Considerations
Official Performance Data
Based on Forklift performance testing:
Cold Migration Performance
Single ESXi Host Scaling:
- Linear performance relationship with VM count
- Optimal performance at 10 VMs per ESXi host
- 100 VMs on single ESXi: ~3 hours 25 minutes
- Performance degrades with oversubscription beyond 10 VMs/host
Multi-Host Performance Improvement:
- 100 VMs across 4 ESXi hosts: ~1 hour 22 minutes (40% improvement)
- 100 VMs across 5 ESXi hosts: ~1 hour 5 minutes (68% improvement)
- Significant performance gains with distributed architecture
Network Performance Analysis
Management vs. Private Networks:
- Equivalent performance when interface speeds match
- No significant degradation using management networks
- Network speed more important than network type
- 10GbE provides substantial improvements over 1GbE
Performance Optimization Strategies
Cold Migration Optimization
Infrastructure Distribution:
1
2
3
4
5
# Distribute VMs across multiple ESXi hosts for better performance
kubectl mtv create plan distributed-cold \
--source-query "where esxiHost in ('host1', 'host2', 'host3')" \
--migration-type cold \
--convertor-node-selector "performance=high"
Resource Allocation:
1
2
3
4
5
# Optimize convertor pod placement for performance
kubectl mtv create plan optimized-cold \
--migration-type cold \
--convertor-node-selector "storage=nvme,network=10gbe" \
--convertor-affinity "REQUIRE nodes(storage-tier=premium) on node"
Warm Migration Optimization
Precopy Scheduling:
1
2
3
# Start precopy during low-activity periods
kubectl mtv start plan production-warm \
--cutover "$(date -d 'next Sunday 2:00 AM' --iso-8601=seconds)"
Change Rate Management:
- Monitor VM activity patterns before migration
- Schedule precopy during predictable low-activity periods
- Consider application-specific quiescing for high-change VMs
- Use multiple precopy iterations for very active systems
Live Migration Optimization
Network Requirements:
- Minimum 10GbE connectivity between clusters
- Low-latency network paths (< 10ms RTT optimal)
- Dedicated migration network bandwidth
- Quality of Service (QoS) configuration
Storage Requirements:
- Shared storage or high-performance replication
- Consistent storage classes and performance tiers
- Optimized storage network connectivity
- Sufficient IOPS for concurrent operations
Monitoring and Validation
Performance Metrics
Key Performance Indicators:
- Total migration time per VM
- Data transfer rates and throughput
- Network utilization and bottlenecks
- Storage performance and latency
- Resource utilization patterns
Monitoring Commands:
1
2
3
4
5
6
7
8
9
10
11
# Monitor migration progress
kubectl mtv get plan migration-performance -w
# Check convertor pod performance
kubectl top pods -l forklift.app/plan=migration-performance
# Analyze network utilization
kubectl exec convertor-pod -- iftop -i eth0
# Monitor storage performance
kubectl exec convertor-pod -- iostat -x 1 5
Best Practices Summary
Migration Type Selection
- Start Conservative: Begin with cold migration for validation and learning
- Progress to Production: Use warm migration for most production workloads
- Reserve Advanced: Apply live migration only for mission-critical KubeVirt scenarios
Planning Recommendations
- Assessment First: Evaluate downtime tolerance before selecting strategy
- Infrastructure Review: Confirm network and storage capabilities
- Pilot Testing: Validate approach with non-critical systems first
- Performance Baseline: Establish expected performance metrics
Risk Mitigation
- Backup Strategy: Ensure comprehensive backup before migration
- Rollback Plan: Document and test rollback procedures
- Monitoring: Implement comprehensive migration monitoring
- Communication: Establish clear stakeholder communication plans
Next Steps
After understanding migration types and strategies:
- Conversion Migration: Learn about external storage vendor integration in Chapter 3.6: Conversion Migration
- Installation Setup: Ensure proper kubectl-mtv installation in Chapter 2: Installation and Prerequisites
- Quick Start: Try your first migration in Chapter 3: Quick Start - First Migration Workflow
- Provider Setup: Configure source platforms in Chapter 4: Provider Management
- Advanced Planning: Explore detailed migration planning in Chapter 10: Migration Plan Creation
Previous: Chapter 3: Quick Start - First Migration Workflow
Next: Chapter 3.6: Conversion Migration