How to migrate from VMware to HyperCloud

Easy paths to true on-prem cloud

Over my career, I’ve worked with VMware extensively - not really a surprise when it was the first tool to begin popularising the virtualisation movement back in the late 90s. Over the years, I’ve poked around under the hood with VMware and learned a lot about NSX, vRealize, vSAN and other pieces. Since being introduced to HyperCloud through my work at SoftIron, I’ve found that HyperCloud does more of what I like and less of what I don’t. If you want to know more about what you gain from migrating to Hypercloud as your cloud platform, I outlined some of the most compelling reasons in “From VMware to HyperCloud”.

If the latest news from VMware has you concerned for the future of your solution, or you’re just tired of all the headaches, this guide will walk you through the process of migrating your VMs from VMware to HyperCloud.

There’s an easy way to migrate - here’s how you do it.

Use case 1: Simple VM migration

Plenty of us have suffered from VM sprawl down the years - the prospect of tackling sprawl head-on can seem daunting but it doesn’t need to be!

Tools have been developed to tackle migration from many sources, and we have built esx2hc around the popular virt-v2v migration utility. Virt-v2v takes the migration pain away by intelligently converting both the virtual machine disk data and the configuration data between providers. Esx2hc makes this even easier by setting up some of the temporary files and connection parameters for the user.

Before you start you will need to have a few things set up:

• Download the esx2hc tool (available from your SoftIron support contact)
• SSH access to an ESXi host:
  • Enable SSH in vCenter
  • Ensure firewall allows SSH traffic
  • Set password for the root user
• VMs prepared:
  • VMs vMotioned to the ESXi host
  • VMs to be migrated are powered off
• Address of your HyperCloud:
• A HyperCloud user account able to create VMs/Templates
• SSH access to HyperCloud

Once the prerequisites listed above are met you can start migrating the VMs from that ESXi host:

1. Write ESXi root password into a file or setup key-based authentication.
2. Run esx2hc with the “inventory” command to generate a list of VMs.
3. Edit the generated file in the staging directory, leaving only the VMs to be migrated.
4. Decide whether you need snapshots. Consolidating snapshots takes a lot of time.
5. Run esx2hc the the “convert” command to migrate VMs to HyperCloud.

We are working to validate full vCenter access but for now the process uses a single ESXi host at a time.

A note on accelerated network cards

We have thoroughly tested moving virtual machines in this manner. While the process is generally smooth, one aspect that might require attention is when using accelerated network cards. These cards come with vendor-specific drivers, causing the virtual machine to perceive a transition from the old to the new network card. Linux can efficiently manage this transition using udev rules, ensuring minimal disruption.

On Windows, however, a new network connection may be created, requiring the entry of IP addresses. To streamline this process, consider using a standard, non-accelerated card like the emulated Intel E1000, which maintains uniformity across different providers.

Use case 2: Service provider migration

Service providers typically utilise their virtual machine providers via middleware that integrates usage, billing and tenancy information over the basic IaaS offerings. Customer interactions will often be via in-house APIs that handle user authentication and ensure that usage is accurately billed during service deployment.

Use of a wider variety of in-house APIs often requires bespoke code to be created to integrate each vendor. The modern HyperCloud API covers all aspects of HyperCloud usage and is well documented. (In contrast, the older VMware SOAP API is required to cover all aspects of vSphere and numerous API endpoints are needed to deal with the loosely grouped vSphere, NSX, vRealize product range.)

HyperCloud API provides a single, modern, RESTful API covering all aspects of infrastructure, virtualisation, storage, network and user administration for the cloud system. HyperCloud allows customers to set a CPU/RAM/disk cost and retrieve accounting information from the API without additional extensions.

To aid service providers in their billing operations HyperCloud captures usage information for CPU, RAM, storage and networking. All of this information can be viewed by the service provider and end-users graphically via the UI, or extracted via the API to enable billing and rating at a granular level.

Use case 3: Large private cloud migration

In contrast to service providers, major private cloud providers often implement chargeback after VM creation. Their primary focus is on ensuring fair resource usage rather than precision in billing, and they typically do not require payment authorization before creating VMs. When dealing with a private cloud migration for software projects, the major steps might be:

1. Create tenancy for teams
2. Setup network ingress
3. Test individual user access
4. Connect to CI systems

In large private cloud environments where IT service provisioning for various internal teams is centralized, the primary focus is on creating tenancies and overseeing access management for each team.

These requirements allow for a simpler configuration, and teams typically use Terraform to run their CI/CD workflows against vCenter instances. Users are members of an internal directory service such as Active Directory or another LDAP provider. LDAP credentials are used to validate access to the IaaS. Scheduled CI/CD Terraform jobs may use dedicated service accounts, though development VMs are built using individual developer’s credentials.

Migration of these processes to HyperCloud is exceedingly straightforward; simply replace the VMware Terraform Provider with the HyperCloud Terraform Provider. Users will then be able to deploy VMs on HyperCloud by choosing a cloud image with QCOW2 or RAW image format in place of their current VMDK format.

Now is the time to prepare for VMware migration.

With change and uncertainty currently plaguing VMware, not to mention the ever-growing complexities created as a by-product of how VMware has evolved over the years it’s good to be aware of your options.