{"id":761,"date":"2026-10-06T17:43:12","date_gmt":"2026-10-06T16:43:12","guid":{"rendered":"https:\/\/www.mrpaulclarke.co.uk\/?page_id=761"},"modified":"2026-10-06T17:49:18","modified_gmt":"2026-10-06T16:49:18","slug":"case-study-migrating-vms-from-one-hypervisor-to-another","status":"publish","type":"page","link":"https:\/\/www.mrpaulclarke.co.uk\/?page_id=761","title":{"rendered":"Case Study – Migrating VM’s from One Hypervisor to another"},"content":{"rendered":"\r\n

🚀 Migrating VMware Virtual Machines to Scale Computing HC3<\/h1>\r\n\r\n\r\n\r\n

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.<\/strong><\/p>\r\n\r\n\r\n\r\n

The organisation was moving away from its existing VMware infrastructure and onto Scale Computing HC3<\/strong>.<\/p>\r\n\r\n\r\n\r\n

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.<\/p>\r\n\r\n\r\n\r\n

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.<\/p>\r\n\r\n\r\n\r\n\r\n

\r\n\r\n\r\n

📈 The Project at a Glance<\/h3>\r\n\r\n\r\n\r\n
\r\n\r\n\r\n
\r\n\r\n

🖥️ SOURCE<\/strong>
VMware
Virtual Machines<\/p>\r\n\r\n<\/div>\r\n\r\n\r\n\r\n

\r\n\r\n

📦 EXPORT<\/strong>
Consolidate
VHDX<\/p>\r\n\r\n<\/div>\r\n\r\n\r\n\r\n

\r\n\r\n

🔄 CONVERT<\/strong>
VHDX
to QCOW2<\/p>\r\n\r\n<\/div>\r\n\r\n\r\n\r\n

\r\n\r\n

✅ RESULT<\/strong>
Scale HC3
Production<\/p>\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div><\/div>\r\n\r\n\r\n\r\n\r\n

\r\n\r\n\r\n\r\n\r\n

🖥️ The Challenge<\/h2>\r\n\r\n\r\n\r\n

The existing production servers were running as virtual machines within a VMware environment.<\/p>\r\n\r\n\r\n\r\n

The new platform was a Scale Computing HC3<\/strong> cluster, which meant the workloads needed to be moved between two different virtualisation platforms.<\/p>\r\n\r\n\r\n\r\n

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.<\/p>\r\n\r\n\r\n\r\n\r\n

\r\n\r\n\r\n
\r\n\r\n\r\n

⚠️ Migration Challenges<\/h3>\r\n\r\n\r\n\r\n
    \r\n
  • Production VMware workloads<\/li>\r\n
  • Existing VMware snapshots<\/li>\r\n
  • Different virtual disk formats<\/li>\r\n
  • Different virtual storage controllers<\/li>\r\n
  • Windows VIRTIO drivers not initially installed<\/li>\r\n
  • Downtime needed to be controlled<\/li>\r\n<\/ul>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n\r\n
    \r\n\r\n\r\n

    🎯 The Objective<\/h3>\r\n\r\n\r\n\r\n
      \r\n
    • Move workloads onto Scale HC3<\/li>\r\n
    • Preserve the existing Windows installations<\/li>\r\n
    • Avoid rebuilding servers unnecessarily<\/li>\r\n
    • Validate each VM before production use<\/li>\r\n
    • Retire the VMware workloads safely<\/li>\r\n<\/ul>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n<\/div>\r\n\r\n\r\n\r\n\r\n
      \r\n

      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.<\/strong><\/p>\r\n<\/blockquote>\r\n\r\n\r\n\r\n\r\n

      \r\n\r\n\r\n\r\n\r\n

      🔍 1. Audit and Prepare the VMware VMs<\/h2>\r\n\r\n\r\n\r\n

      The first stage was to review the existing VMware virtual machines and make sure they were in a suitable state for migration.<\/p>\r\n\r\n\r\n\r\n

      Particular attention was paid to the virtual disk configuration and any snapshots associated with the machines.<\/p>\r\n\r\n\r\n\r\n

      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.<\/p>\r\n\r\n\r\n\r\n\r\n

      \r\n\r\n\r\n

      🔎 Pre-Migration Checks<\/h3>\r\n\r\n\r\n\r\n
        \r\n
      • Review each virtual machine<\/li>\r\n
      • Check attached virtual disks<\/li>\r\n
      • Identify existing snapshots<\/li>\r\n
      • Confirm the current production state<\/li>\r\n
      • Plan the migration and validation process<\/li>\r\n<\/ul>\r\n\r\n\r\n<\/div><\/div>\r\n\r\n\r\n\r\n\r\n
        \r\n\r\n\r\n\r\n\r\n

        🧩 2. Consolidate the VMware Snapshots<\/h2>\r\n\r\n\r\n\r\n

        Where VMware snapshots existed, these needed to be consolidated before the virtual machines were exported.<\/p>\r\n\r\n\r\n\r\n

        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.<\/p>\r\n\r\n\r\n\r\n

        Once consolidation had completed successfully, the virtual machine was in a much cleaner state for the next stage of the migration.<\/p>\r\n\r\n\r\n\r\n\r\n

        \r\n

        Cleaning up the source VM before migration removes unnecessary complexity from everything that follows.<\/strong><\/p>\r\n<\/blockquote>\r\n\r\n\r\n\r\n\r\n

        \r\n\r\n\r\n\r\n\r\n

        📦 3. Export the Virtual Machine as VHDX<\/h2>\r\n\r\n\r\n\r\n

        With the VMware snapshots consolidated, the virtual machines could be exported using the available VMware tools<\/strong>.<\/p>\r\n\r\n\r\n\r\n

        The resulting virtual disks were exported in VHDX<\/strong> format, providing the files that would then be imported into the Scale HC3 environment.<\/p>\r\n\r\n\r\n\r\n

        This provided a clear hand-off point between the existing VMware infrastructure and the new Scale platform.<\/p>\r\n\r\n\r\n\r\n\r\n

        \r\n\r\n\r\n

        🔄 Migration Path<\/h3>\r\n\r\n\r\n\r\n

        VMware \u2192 VHDX \u2192 Scale HC3 \u2192 QCOW2<\/strong><\/p>\r\n\r\n\r\n<\/div><\/div>\r\n\r\n\r\n\r\n\r\n

        \r\n\r\n\r\n\r\n\r\n

        🔄 4. Import the VHDX into Scale HC3<\/h2>\r\n\r\n\r\n\r\n

        The exported VHDX files were then uploaded into the Scale Computing HC3<\/strong> environment.<\/p>\r\n\r\n\r\n\r\n

        One of the useful features of HC3 was its ability to handle the disk conversion as part of the import process.<\/p>\r\n\r\n\r\n\r\n

        Rather than manually converting each VHDX using a separate conversion utility, HC3 performed the necessary conversion and created the virtual disk in QCOW2<\/strong> format for use by the new virtual machine.<\/p>\r\n\r\n\r\n\r\n\r\n

        \r\n\r\n\r\n

        ✨ Let HC3 Do the Conversion<\/h3>\r\n\r\n\r\n\r\n

        The source disk arrived as VHDX, but the destination VM needed a QCOW2 disk.<\/p>\r\n\r\n\r\n\r\n

        Scale HC3 handled that conversion during the import process, removing the need for an additional manual disk-conversion stage.<\/p>\r\n\r\n\r\n<\/div><\/div>\r\n\r\n\r\n\r\n\r\n

        \r\n\r\n\r\n\r\n\r\n

        💡 5. Solve the Windows Storage Driver Problem<\/h2>\r\n\r\n\r\n\r\n

        Converting the virtual disk was only part of the challenge.<\/p>\r\n\r\n\r\n\r\n

        The migrated Windows installation had previously been running under VMware and didn’t yet have the required VIRTIO storage driver<\/strong> available for the new HC3 virtual hardware.<\/p>\r\n\r\n\r\n\r\n

        If the converted disk was immediately attached using VIRTIO, Windows would not necessarily be able to access its own boot disk.<\/p>\r\n\r\n\r\n\r\n

        The solution was to initially attach the migrated disk using an IDE controller<\/strong>. This allowed Windows to boot successfully using a storage controller it could already recognise.<\/p>\r\n\r\n\r\n\r\n\r\n

        \r\n\r\n\r\n

        🛠️ The IDE \u2192 VIRTIO Technique<\/h3>\r\n\r\n\r\n\r\n
          \r\n
        1. Attach the converted QCOW2 disk to the new HC3 VM as IDE<\/strong>.<\/li>\r\n
        2. Boot Windows using the IDE controller.<\/li>\r\n
        3. Install the required Scale \/ VIRTIO drivers<\/strong>.<\/li>\r\n
        4. Shut down the virtual machine.<\/li>\r\n
        5. Change the virtual disk controller from IDE to VIRTIO<\/strong>.<\/li>\r\n
        6. Boot Windows again and confirm the disk is recognised correctly.<\/li>\r\n<\/ol>\r\n\r\n\r\n<\/div><\/div>\r\n\r\n\r\n\r\n\r\n
          \r\n

          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.<\/strong><\/p>\r\n<\/blockquote>\r\n\r\n\r\n\r\n\r\n

          \r\n\r\n\r\n\r\n\r\n

          ⚙️ 6. Configure the HC3 Virtual Machine<\/h2>\r\n\r\n\r\n\r\n

          Once the storage-driver issue had been addressed, the virtual machine could be configured properly within HC3.<\/p>\r\n\r\n\r\n\r\n

          The appropriate virtual CPU, memory, networking and storage configuration could then be applied to the migrated workload.<\/p>\r\n\r\n\r\n\r\n

          The VM was booted again using its final configuration and checked for any issues caused by the change of virtualisation platform.<\/p>\r\n\r\n\r\n\r\n\r\n

          \r\n\r\n\r\n\r\n\r\n

          🧪 7. Validate the Migrated Server<\/h2>\r\n\r\n\r\n\r\n

          A successful Windows boot didn’t automatically mean the migration was complete.<\/p>\r\n\r\n\r\n\r\n

          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.<\/p>\r\n\r\n\r\n\r\n\r\n

          \r\n\r\n\r\n
          \r\n\r\n\r\n

          🖥️ Operating System<\/h3>\r\n\r\n\r\n\r\n