🚀 Migrating VMware Virtual Machines to Scale Computing HC3

Moving virtual machines between hypervisors isn’t always as simple as copying a virtual disk. This project involved migrating production VMware workloads onto a Scale Computing HC3 cluster while keeping downtime and risk to a minimum.

The organisation was moving away from its existing VMware infrastructure and onto Scale Computing HC3.

The challenge was to migrate the existing Windows virtual machines safely, deal with the differences between the two virtualisation platforms and make sure each server could boot successfully on HC3 before the original VMware environment was retired.

The migration involved consolidating VMware snapshots, exporting the virtual machines as VHDX files, allowing HC3 to convert those disks into its native QCOW2 format and then handling the Windows storage-driver transition from IDE to VIRTIO.

---

🖥️ The Challenge

The existing production servers were running as virtual machines within a VMware environment.

The new platform was a Scale Computing HC3 cluster, which meant the workloads needed to be moved between two different virtualisation platforms.

This wasn’t simply a case of copying the existing virtual disks. The VMware virtual machines needed to be prepared correctly, exported into a format HC3 could ingest, converted into the HC3 disk format and then made bootable using the appropriate virtual storage drivers.

The goal wasn’t simply to move virtual disks. The goal was to move complete production workloads onto a different hypervisor and have them behave exactly as expected.

---

🔍 1. Audit and Prepare the VMware VMs

The first stage was to review the existing VMware virtual machines and make sure they were in a suitable state for migration.

Particular attention was paid to the virtual disk configuration and any snapshots associated with the machines.

Before exporting a production workload, it was important to understand exactly what was attached to each VM and ensure that the exported machine would represent the current production state.

---

🧩 2. Consolidate the VMware Snapshots

Where VMware snapshots existed, these needed to be consolidated before the virtual machines were exported.

This ensured the current state of the server was represented within the virtual disk being prepared for migration rather than leaving the production data spread across a base disk and one or more snapshot files.

Once consolidation had completed successfully, the virtual machine was in a much cleaner state for the next stage of the migration.

Cleaning up the source VM before migration removes unnecessary complexity from everything that follows.

---

📦 3. Export the Virtual Machine as VHDX

With the VMware snapshots consolidated, the virtual machines could be exported using the available VMware tools.

The resulting virtual disks were exported in VHDX format, providing the files that would then be imported into the Scale HC3 environment.

This provided a clear hand-off point between the existing VMware infrastructure and the new Scale platform.

---

🔄 4. Import the VHDX into Scale HC3

The exported VHDX files were then uploaded into the Scale Computing HC3 environment.

One of the useful features of HC3 was its ability to handle the disk conversion as part of the import process.

Rather than manually converting each VHDX using a separate conversion utility, HC3 performed the necessary conversion and created the virtual disk in QCOW2 format for use by the new virtual machine.

---

💡 5. Solve the Windows Storage Driver Problem

Converting the virtual disk was only part of the challenge.

The migrated Windows installation had previously been running under VMware and didn’t yet have the required VIRTIO storage driver available for the new HC3 virtual hardware.

If the converted disk was immediately attached using VIRTIO, Windows would not necessarily be able to access its own boot disk.

The solution was to initially attach the migrated disk using an IDE controller. This allowed Windows to boot successfully using a storage controller it could already recognise.

Sometimes the difficult part of a virtual-machine migration isn’t moving the disk. It’s making sure the operating system knows how to talk to its new virtual hardware.

---

⚙️ 6. Configure the HC3 Virtual Machine

Once the storage-driver issue had been addressed, the virtual machine could be configured properly within HC3.

The appropriate virtual CPU, memory, networking and storage configuration could then be applied to the migrated workload.

The VM was booted again using its final configuration and checked for any issues caused by the change of virtualisation platform.

---

🧪 7. Validate the Migrated Server

A successful Windows boot didn’t automatically mean the migration was complete.

Each migrated server needed to be checked to make sure the operating system, network connectivity and application services were behaving correctly on the new platform.

---

🚀 8. Move the Workload into Production

Once testing confirmed the migrated VM was operating correctly on HC3, the workload could be moved into production.

Final checks ensured users and dependent systems could reach the migrated server and that its applications and services were functioning as expected.

Only once the HC3 version of the server had been proven was the original VMware workload ready to be retired.

---

🗑️ 9. Retire the VMware VM

With the migrated workload running successfully on Scale HC3, the original VMware virtual machine was no longer required for production.

Retiring the old workload removed the risk of accidentally starting or using two copies of the same production server and formed part of the wider move away from the legacy VMware platform.

A migration is only complete when the new workload has been proven and the old one is no longer part of the production environment.

---

📈 The Result

The existing Windows workloads were successfully moved from VMware onto the Scale Computing HC3 platform without having to rebuild the servers from scratch.

---

🛠️ Technologies & Skills

---

🚀 Planning a Hypervisor Migration?

Moving workloads between virtualisation platforms involves more than simply copying virtual disks. Storage formats, virtual hardware, drivers, networking and application dependencies all need to be considered.

I can help assess existing virtual infrastructure, plan the migration path and move workloads onto a new platform while keeping disruption and risk under control.