VMware Relocate Source Readiness

Purpose

Use this runbook before assigning VMware virtual machines to a Relocate wave. It turns discovery evidence into a technical source-readiness decision and separates common VMware checks from the requirements of Cloudbase Coriolis and Hystax Acura.

The output is a per-VM readiness record with supported, conditional, or blocked status. Resolve blocked items before replication begins instead of moving uncertainty into the cutover window.

Required inputs

• VM inventory: vCenter, cluster, host, datastore, VM hardware version, firmware, operating system, VMware Tools state, virtual disks, controllers, NICs, addresses, and attached devices.
• Workload context: Application owner, criticality, dependencies, consistency requirements, recovery objectives, allowed downtime, and rollback tolerance.
• Performance evidence: Representative CPU, memory, IOPS, throughput, latency, queue, capacity, and growth data rather than provisioned VMware capacity alone.
• Migration path: Selected tool, Coriolis or Acura, and its current source and target compatibility matrix.

Common VMware readiness checks

Guest and virtual hardware

1. Confirm that the guest operating system, architecture, file systems, partition layout, and boot mode are supported by the selected tool and STACKIT target.
2. Record BIOS or UEFI firmware, Secure Boot, virtual disk controllers, NIC models, static routes, and guest-specific drivers that may require conversion or replacement.
3. Identify encrypted disks, Raw Device Mappings, shared disks, independent disks, passthrough devices, nested virtualization, and removable media. Treat each unsupported attachment as a blocker or design an explicit replacement.
4. Verify current VMware Tools health. Even where the migration tool is agentless, current guest tools improve inventory quality, snapshot coordination, and controlled shutdown behavior.
5. Confirm operating-system licensing and activation behavior after the virtual hardware and cloud environment change.

Source health and snapshot safety

1. Resolve active alarms, failed backups, orphaned snapshots, snapshot consolidation warnings, and file-system or volume errors before replication.
2. Verify that application-consistent or crash-consistent snapshots meet the workload’s recovery requirements. Databases and other stateful systems may need application quiescing or native replication in addition to VM replication.
3. Reserve datastore capacity for migration snapshots and change tracking. Include current growth, expected write rate, replication duration, and retry margin in the capacity decision.
4. Test backup restoration independently of the migration tooling and retain a recovery point that predates the first migration operation.

Network and access path

1. Measure available bandwidth, latency, packet loss, and the daily data-change rate between source and target. Confirm that the initial copy and subsequent deltas fit the planned wave schedule.
2. Validate DNS, NTP, MTU, proxy, routing, NAT, and firewall behavior across management and data paths. Record every required source, destination, protocol, port, and owner.
3. Use dedicated, least-privilege service accounts for vCenter or ESXi and the STACKIT target. Validate API access and certificate trust before creating endpoints.
4. Confirm target address allocation, security groups, DNS changes, load-balancer changes, and the traffic-switch mechanism. Replication software does not replace the cutover network runbook.

Coriolis readiness path

Apply these checks when Cloudbase Coriolis is selected:

1. Validate the supported VMware source and STACKIT destination endpoint versions against the Coriolis release used for the wave.
2. Create and test the VMware endpoint with a dedicated API identity. Confirm that Coriolis can enumerate the selected VMs, disks, networks, and storage required by the migration scope.
3. Create and validate the STACKIT destination endpoint, then define source and destination minion pools with enough worker capacity and concurrency for the planned wave.
4. Define source-to-target network and storage mappings before creating Transfer and Deployment definitions. Review the destination machine type, boot volume, data volumes, and security groups.
5. Validate minion-worker and data-transfer connectivity required by the deployed architecture. Do not assume that HTTPS access to the Coriolis user interface proves migration-path readiness.
6. Review guest conversion and OS-morphing support, including bootloader, storage driver, network driver, and cloud initialization behavior. Mark workloads requiring manual remediation.

The Coriolis STACKIT Installer deploys and configures the Coriolis appliance on STACKIT. It does not create VMware permissions, resolve unsupported source devices, size target VMs, or validate the source-to-target transfer path.

Cloud Framework Coriolis STACKIT Installer Deploy the Coriolis appliance reproducibly after source and target prerequisites are understood. Open page

Hystax Acura readiness path

Apply these checks when Hystax Acura is selected:

1. Confirm that VMware Tools is installed and running on every selected VM.
2. Verify that Changed Block Tracking and VMware snapshots can be used for the selected virtual disks and that no conflicting snapshot operation is active.
3. Keep at least 10 percent free capacity on source datastores and increase that margin for high-change workloads or long replication windows.
4. Provide the documented vSphere API permissions and validate connectivity to vCenter or ESXi on TCP ports 443 and 902 from the Acura components that perform discovery and replication.
5. Deploy and validate the required Hystax replication agents on the source ESXi hosts before scheduling the first full replication.
6. Plan at least one isolated test migration. Traffic redirection, DNS changes, and application freeze remain explicit cutover-runbook activities outside Acura replication.

Readiness decision

Record the result for every VM and preserve the evidence used for the decision.

• Guest compatibility: Pass with a supported operating system, boot mode, disk layout, and conversion path. Block on an unsupported device, encryption method, architecture, or boot path.
• Source integrity: Pass with a healthy VM, tested recovery point, and safe snapshot state. Block on a consolidation error, failed backup, or insufficient datastore capacity.
• Performance baseline: Pass with representative CPU, memory, storage, and growth measurements. Block when only provisioned capacity or incomplete peak-window data is available.
• Access: Pass with tested least-privilege endpoint credentials and certificate trust. Block on missing API permissions or unmanaged shared credentials.
• Transfer path: Pass with measured capacity and validated routing, ports, DNS, NTP, and MTU. Block on firewall gaps, unstable links, or a copy duration outside the wave schedule.
• Cutover inputs: Pass with target mappings, validation tests, a rollback trigger, and source retention. Block on an undefined traffic switch or rollback path that cannot be tested.

Approve a VM for replication only when every blocker has an owner and resolution date. Conditional items must have an executable remediation step in the wave runbook; observations without impact can remain in the evidence record.

Primary references

External source cloudbase.it Cloudbase Coriolis Open external site Leads off the trail External source hystax.com Hystax Acura Live Migration Open external site Leads off the trail