Migration Architecture

Technical architecture of the VMware-to-OpenStack migration pipeline — warm migration, disk transfer, OS conversion, and flavor matching.

Migration Architecture

The migration pipeline moves virtual machines from VMware vSphere to OpenStack with automatic disk conversion, flavor matching, and optional near-zero downtime via Changed Block Tracking.

High-Level Flow

┌──────────────┐                                      ┌──────────────────┐
│   VMware     │    FFO Digital Twin                   │    OpenStack     │
│   vCenter    │    ┌──────────────┐                   │    (Target)      │
│              │───▶│  Migration   │───▶               │                  │
│  VMs         │    │  State       │    Migration       │  Nova Instances  │
│  Networks    │    │  Tracking    │    Engine          │  Cinder Volumes  │
│  Datastores  │    └──────────────┘                   │  Neutron Networks│
└──────────────┘                                      └──────────────────┘
       ▲                                                      ▲
       │              ┌──────────────┐                        │
       └──────────────│  MCP Servers │────────────────────────┘
                      │  VMware (8)  │
                      │  OpenStack(54)│
                      └──────────────┘

Migration Pipeline

Phase 1: Discovery

The VMware MCP server queries your vCenter to enumerate every VM with its full configuration:

  • vCPU count and memory allocation
  • Disk layout (VMDK paths, sizes, thin/thick provisioning, controller types)
  • Network attachments (port groups, MAC addresses)
  • Guest OS identification
  • Cluster and host placement
  • Power state

This inventory is written to the FFO knowledge graph, creating a complete digital twin of the source environment.

Phase 2: Flavor Matching

For each source VM, the migration engine queries the OpenStack MCP server for available flavors and finds the closest match:

  • Flavor vCPUs must be ≥ source vCPUs
  • Flavor RAM must be ≥ source memory
  • Among qualifying flavors, the smallest (least resource waste) is selected
  • Boot-from-volume flavors are preferred for migrated workloads
  • If no existing flavor fits, one can be created automatically

Example: a VMware VM with 4 vCPUs and 16GB RAM would match an OpenStack flavor with 4 vCPUs and 16GB RAM (or the next size up if no exact match exists).

Phase 3: Network Mapping

VMware port groups are mapped to OpenStack Neutron networks via the FFO knowledge graph. The platform identifies:

  • Mapped networks — source port groups with a confirmed target network (green)
  • Unmapped networks — port groups with no corresponding OpenStack network (flagged for human review before migration begins)
  • MAC preservation — where possible, the migration creates OpenStack ports with the same MAC addresses as the source NICs

Network mapping gaps are surfaced in the Migration Monitor dashboard before any migration begins, not discovered mid-flight.

Phase 4: Disk Transfer

Two pipelines are available, auto-selected based on environment:

Pipeline A: VDDK (Maximum Throughput)

For environments with VMware VDDK available:

  1. Snapshot source VM (migration-consistent point-in-time)
  2. nbdkit with VDDK plugin exposes each VMDK as an NBD endpoint
  3. nbdcopy streams disk blocks from NBD to OpenStack Cinder volumes
  4. For warm migration: CBT (Changed Block Tracking) enables incremental delta syncs — only changed blocks are copied after the initial full copy
  5. Parallel streams for multi-disk VMs

Throughput: 100–200 MB/s per disk stream depending on network and storage.

Pipeline B: Open Source (Zero Proprietary Dependencies)

The default pipeline for federal environments where proprietary VMware SDKs cannot be deployed:

  1. VMware REST API downloads VMDK flat files via authenticated HTTP
  2. qemu-img converts VMDK to raw format
  3. Raw image uploaded to OpenStack Glance or written directly to Cinder volumes
  4. No proprietary software required — entirely open-source toolchain

Pipeline B is slower than Pipeline A but requires nothing beyond standard open-source tools. It is the recommended default for classified and air-gapped environments.

Phase 5: OS Conversion

Disk images from VMware need conversion for the KVM hypervisor used by OpenStack:

  • virt-v2v (Red Hat’s open-source conversion tool) handles full in-place conversion:
    • Injects virtio drivers for KVM disk and network I/O
    • Fixes bootloader configuration (GRUB, UEFI)
    • Adjusts device references (/dev/sd* → /dev/vd*)
    • For Windows VMs: injects virtio drivers and configures first-boot scripts
  • Minimal conversion path for modern Linux VMs that already include virtio modules — no full virt-v2v pass needed

Phase 6: Instance Launch

The migration engine creates the target Nova instance:

  1. Cinder volumes set as bootable
  2. Nova instance created with matched flavor, boot-from-volume, and pre-created network ports
  3. Instance polled until ACTIVE state
  4. IP address and connectivity verified
  5. Migration state updated to “completed” in FFO

Warm Migration Flow

For production workloads requiring near-zero downtime:

Time ──────────────────────────────────────────────────────▶

VM on VMware:  ██████████████████████████████████░░░
               │        Running (poweredOn)       │Off│
               │                                  │   │
               │◄── Pre-copy (bulk disk sync) ──▶│Cut│
               │    VM stays running              │   │
                                                      │
VM on OpenStack:                                  ░░░████
                                                  │Bld│ Running (ACTIVE)
                                                  │   │
                                                  │◄──── Cutover window
                                                         (seconds)

  1. Pre-copy phase (majority of migration time): Full disk copy via CBT while the VM continues running on VMware. The dashboard shows “Pre-copying disks…” with the VM still green/running.

  2. Cutover (seconds): Final delta sync of blocks changed since the last copy. VM powers off on VMware, instance launches on OpenStack. Dashboard shows brief amber flash.

  3. Active on OpenStack: Instance reaches ACTIVE state with IP assigned. Dashboard shows green on the target side.

The pre-copy phase handles the bulk data transfer while the workload is live. The actual downtime window is limited to the cutover — typically seconds, not minutes.

Layer Architecture

Layer 1: Single-VM Migration Engine

A container-based migration engine that executes the full pipeline for one VM at a time. Exposed as an MCP tool (vmware_migrate_vm) callable by InfrastructureAI agents or directly from the Migration Monitor dashboard.

Layer 2: Fleet Orchestrator (Planned)

For large-scale migrations (thousands of VMs), Layer 2 adds:

  • Wave planning via FFO dependency graph — migrate databases before application servers, shared storage before consumers
  • Parallel execution — multiple Layer 1 instances running concurrently with configurable concurrency limits
  • Progress tracking — fleet-wide migration state in FFO, queryable by agents and visible in the dashboard
  • Failure handling — automatic retry, rollback, skip-and-continue strategies
  • Capacity management — monitors target environment resources to prevent over-provisioning during migration