Overview¶

How Migrations Work¶

The bulk migration tool moves virtual machines from VMware vCenter environments to HVM Clusters. A migration requires:

• One or more integrated VMware vCenter Clouds (source)

• At least one functional HVM Cluster (destination)

See the VMware vCenter integration guide and the HVM Clusters guide elsewhere in this documentation for details on setting up those integrations.

Migration Architecture¶

Migrations use an agent-pull architecture. The Morpheus Agent running on the destination HVM host connects directly to the source VMware environment over HTTPS and streams disk data using VMware’s HttpNfcLease export API. This means:

• No intermediate storage is required — disk data flows directly from ESXi to the target HVM host

• HVM hosts must resolve ESXi FQDNs and have network access to ESXi hosts and vCenter on the source VMware Cloud via the management network; see Requirements for the separate name-resolution and connectivity checks

• Disk format conversion happens in-flight — VMDK data is decompressed and written as QCOW2 (thin-provisioned) or raw format depending on the target datastore

Migration Phases¶

Each VM in a Migration Plan goes through the following phases:

1. Precheck — Verifies the source VM is reachable, sets credentials, and powers on the VM if needed. This step can be skipped when creating the plan.

2. Prepare — Installs QEMU guest tools on the source VM. For Windows, VirtIO drivers are also installed (automatically, with ISO fallback if network installation fails).

3. Create — Provisions a target VM shell on the HVM Cluster. Maps CPU, memory, networks, and storage controllers from the source configuration.

4. Transfer — Powers down the source VM and streams disk data from VMware to the target HVM host. Disks are written as thin-provisioned QCOW2 for GFS2/NFS targets or raw for block devices (including Ceph RBD).

5. Reconfigure (Windows only) — Boots the target VM on temporary SATA disks so Windows can detect and load VirtIO drivers, then shuts down and switches all disks to VirtIO bus.

6. Finalize — Starts the destination VM and marks the migration as complete.

All VMs in a plan are processed in parallel. Plans with many VMs will transfer them simultaneously, limited only by available bandwidth and storage I/O capacity.

Linux Guest Preparation¶

During the Prepare phase, HPE Morpheus Software installs QEMU guest tools and ensures the necessary VirtIO kernel modules are available so the VM can boot successfully on the KVM-based HVM target. The steps performed depend on the Linux distribution family.

Package Installation¶

HPE Morpheus Software uses the source VM’s native package manager to install qemu-guest-agent. The system detects the available package manager and runs the appropriate install command:

The installation is retried up to 3 times with a 30-second pause between attempts if the package manager command fails (e.g., due to transient network issues or locked package databases).

VirtIO Kernel Modules¶

After package installation, HPE Morpheus Software verifies that the following VirtIO kernel modules are available (loaded or loadable) on the source VM:

• virtio_blk — VirtIO block device driver (required for disk access on the target)

• virtio_net — VirtIO network driver (required for network connectivity on the target)

• virtio_scsi — VirtIO SCSI controller driver (used when source disks map to VirtIO-SCSI)

• virtio_pci — VirtIO PCI transport (bus-level driver for all VirtIO devices)

These modules are typically included in the default kernel for all supported distributions. If a module is missing, it must be present in the kernel’s module tree so it can be included during the initramfs rebuild.

Initramfs Rebuild¶

For RHEL-family distributions, the initramfs is rebuilt before package installation using dracut --force --no-hostonly. The --no-hostonly flag ensures that all available kernel modules (including VirtIO drivers) are included in the initramfs regardless of the current running hardware. This is critical because the source VM is running on VMware hardware but must boot on KVM/VirtIO hardware after migration.

For Debian/Ubuntu, VirtIO modules are typically already included in the default initramfs and no explicit rebuild is performed during migration.

For SUSE/SLES, the qemu-guest-tools package installation handles driver availability through the distribution’s standard module inclusion mechanisms.

Network Interface Changes¶

When a VM moves from VMware (vmxnet3 or E1000 adapters) to HVM (VirtIO-net), network interface names may change. The behavior depends on the guest OS configuration:

• Predictable naming (default on most modern distros): Interface names are derived from PCI slot/topology (e.g., ens3, enp1s0). The name will change since the virtual hardware topology differs between VMware and KVM.

• Legacy naming (``eth0``, ``eth1``): If the guest uses legacy naming (via kernel parameter or udev rules), interfaces typically retain their ordinal names.

HPE Morpheus Software does not automatically reconfigure network interface bindings (IP addresses, routes, bonding) during migration. Post-migration, verify that network configuration files reference the correct interface names on the target VM.

Bootloader and fstab¶

• GRUB configuration — Generally requires no changes. The initramfs rebuild ensures VirtIO drivers are loaded early enough for root device access. If the source VM uses device-path references in GRUB (e.g., /dev/sda), these are mapped to the corresponding VirtIO device paths on the target.

• fstab — Entries using UUID or LABEL references (the default on most modern distributions) require no changes. Entries using device paths (e.g., /dev/sda1) may need to be updated post-migration if the device naming changes.

Supported Configurations¶

Required Permissions¶

Users performing migrations require specific RBAC permissions. The table below lists the minimum permissions needed for each type of migration operation.

Bulk Migration (VMware to HVM)¶

Live Migration (Host-to-Host within a Cluster)¶

Storage Migration (Datastore-to-Datastore)¶

Cross-Cloud Move (Record Migration)¶

Permission Dependencies¶

• Services: Migrations requires that the user also has access to both the source Cloud (VMware) and the target Cluster (HVM). Cloud and Group access are controlled via the role’s Cloud and Group permission tabs.

• Infrastructure: Manage Placement requires at minimum Read access to Infrastructure: Clusters and Infrastructure: Compute to view available hosts and capacity.

• Permissions follow the standard HPE Morpheus Software RBAC hierarchy: Tenant Role sets maximum permissions, User Role cannot exceed Tenant Role limits.

Recommended Role Examples¶