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

  1. Pre-Migration Validation
    • Verify source VM health and configuration
    • Confirm target resource availability
    • Validate network and storage mappings
    • Schedule maintenance window
  2. Migration Execution
    • Gracefully shutdown source VM
    • Begin disk data transfer to target storage
    • Monitor transfer progress and performance
    • Validate data integrity during transfer
  3. Post-Migration Activation
    • Complete final data validation
    • Configure target VM settings
    • Start target VM in destination environment
    • Verify application functionality
  4. 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

  1. 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
  2. Integration Requirements
    • Do you have compatible storage vendor solutions? –> Consider Conversion Migration (VMware only)
    • Need standard Forklift-managed migration? –> Proceed to downtime assessment
  3. Downtime Requirements
    • Can tolerate hours of downtime? –> Cold Migration
    • Need minimal downtime (minutes)? –> Warm Migration
    • Require near-zero downtime (seconds)? –> Live Migration (KubeVirt only)
  4. Complexity Tolerance
    • Prefer simple, predictable process? –> Cold Migration
    • Accept moderate complexity for reduced downtime? –> Warm Migration
    • Have advanced technical capabilities? –> Live Migration
  5. 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:

  1. Phase 1: Cold migration for non-critical systems (validation)
  2. Phase 2: Warm migration for production workloads (standard approach)
  3. 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

  1. Start Conservative: Begin with cold migration for validation and learning
  2. Progress to Production: Use warm migration for most production workloads
  3. Reserve Advanced: Apply live migration only for mission-critical KubeVirt scenarios

Planning Recommendations

  1. Assessment First: Evaluate downtime tolerance before selecting strategy
  2. Infrastructure Review: Confirm network and storage capabilities
  3. Pilot Testing: Validate approach with non-critical systems first
  4. Performance Baseline: Establish expected performance metrics

Risk Mitigation

  1. Backup Strategy: Ensure comprehensive backup before migration
  2. Rollback Plan: Document and test rollback procedures
  3. Monitoring: Implement comprehensive migration monitoring
  4. Communication: Establish clear stakeholder communication plans

Next Steps

After understanding migration types and strategies:

  1. Conversion Migration: Learn about external storage vendor integration in Chapter 3.6: Conversion Migration
  2. Installation Setup: Ensure proper kubectl-mtv installation in Chapter 2: Installation and Prerequisites
  3. Quick Start: Try your first migration in Chapter 3: Quick Start - First Migration Workflow
  4. Provider Setup: Configure source platforms in Chapter 4: Provider Management
  5. 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