Conversion of VMware to Hyper-V

[Chris_Lionetti]

This is the first part of the VMware conversion blog series. In this blog, we will be showing the steps needed to convert a VMWare VM to a Hyper-V VM. Additional blogs in this series will cover the conversion to other platforms such as Azure Local.

The first step to convert these VMs is to install a trial version of System Center Virtual Machine Manager (SCVMM). This is the same ISO base as the full version and is only turned into a ‘trial’ by skipping the adding of a license key. This trial version will function for 90 days and can be renewed to extend an additional 90 days. After that period if more VMs need to be converted, a new installation of SCVMM will be required, or you can license the product.

For this conversion you will need a Virtual Machine with sufficient CPU and Memory to host System Center Virtual Machine Manager (SCVMM). The SCVMM software comes in four pieces, that for large installations can be separated into separate virtual machines, but if you are using SCVMM only for conversion purposes, you can host all 4 personalities on a single virtual Machine. These different functions are as follows.

1. VMM Server
2. VMM Database
3. VMM Library
4. VMM Console

Note: If you plan to continue using SCVMM as a replacement for vSphere, you may wish to make this installation more permanent from the start and install these functions on individual servers. Installing these functions together limits the scale of operations that SCVMM can support in an ongoing private cloud. When these functions are separated into separate servers, SCVMM can scale to 25,000 Virtual Machines and 1,000 Physical Hosts under management.

It is recommended that this virtual machine be based on a new installation of Windows Server 2022/2025 Standard Edition. The recommended server requirements are listed below.

• 8 Cores
• 16 GB of RAM   
• 250GB of HDD space
• 10Gb/s Ethernet

In addition to the SCVMM installation you will want to install a Windows Failover Cluster to host the Hyper-V VMs. This should be a multi-node cluster and can connect to SAN based storage to host the many Virtual Machines. This allows customers to continue using high performance SAN infrastructure already in place. Some allowances will need to be made however to ensure that enough free space on the storage exists to host the new Hyper-V VMs.  These new VMs significantly expand required space as they are deployed while leaving the existing VMware VMs in place until the new VMs are accepted and possibly until the backup window catches up with the new Hyper-V Platform.  That is,  If you keep 30 days of daily backups of your VMs, you will want to convert the VM to Hyper-V, but leave the VMWare VM intact until that 30 day window has expired such that you know you have a 30 day backup window on the new platform.

Licensing

The first variable you will need to solve is with regards to licensing. If you choose the Windows Server 2022/2025 DataCenter license for your Hyper-V Physical Servers, the initial server licensing costs will be higher, but all VMs that you host on those Physical Servers will automatically be licensed.

However, if you are converting from VMware to Hyper-V, it is likely that your organization already owns the standalone licenses for your Windows Server VMs. Additionally, no additional licensing is needed for non-Microsoft operating systems such as Linux. If you are planning to add many new Microsoft OS based VMs, a Windows Server DataCenter license may save you money in the long run. Alternatively, you can choose to deploy multiple Windows Failover Clusters, such that one cluster is based on Windows Server Standard and may host the Virtual Machines that are either self-licensed or are Linux type VMs, while the next cluster could be Windows Server DataCenter and may host all new Windows Installations. There are many options to consider, and the larger the infrastructure the more likely you can optimize your final solution. However, this comes with added complexity. To be more operationally agile (but less optimized for costs), you can simply choose to outfit all the Physical Servers with Windows DataCenter Licenses.  

Windows Failover Cluster Size

When Deploying VMs, careful consideration should be made regarding how many nodes to deploy. Below are a list of benefits and disadvantages to each of the node counts possible.

Two Node Clusters: This is the simplest version of clustering to deploy, and gives you all the benefits of a fully redundant cluster. What it lacks however is serviceability and cost effectiveness. When deploying a Two-Node cluster, you will be required to purchase high-core count CPUs to handle the workload.  That is, if the combined required Logical Processors are 400, and required RAM is 2TB, you will need to purchase each node with enough spare capacity such that all VMs can be run from the surviving node (if a node were to fail or require reboot for, or for an update). In this case, each Logical Processor is a thread, and each Core supplies two threads. So, you will need 200 Cores, and within a single server, that will likely mean you must deploy a physical server capable of supporting 2 sockets, and 100 cores per socket. This represents a redundancy tax of 100% and is the least efficient method to deploy your nodes. To maintain Quorum, a single node with access to a Quorum disk or quorum file share is sufficient. 

Three-Node Clusters: This mode of deployment offers significant advantages over the 2-node cluster since you only need enough spare capacity to support 1 failed node out of three, which means that instead of limiting your Core utilization to ½ of each server (50% workload), your servers can be loaded up to 2/3 of each server (66%). This also offers freedom to choose more cost-effective processors and memory.

Four-Node and Greater Clusters: This is the recommendation, to start at four-nodes and grow as needed. It offers at least a 75% load capability while allowing for the failure of one node. Additionally, with modern core counts (hundreds of Cores per Node) these small clusters can be highly efficient and adding more nodes is a relatively simple process.

Greater than 8 or 16 Node Clusters: Considerations should be made to determine if the cluster should be scaled up or instead another Windows Failover Cluster should be created. As the cluster size grows, the failure domain also increases. The Complexity of the cluster grows, and processes like Cluster Aware Updating can take extended periods of time to complete since it is a serial process that requires one Node of the cluster to reboot at a time. Additionally, adding more Fibre Channel or iSCSI Volumes to a Windows Failover Cluster requires configuration updates on ALL nodes of the cluster. While this can be automated, it still represents a significant task to accomplish on 16 nodes. It should be noted that Windows Failover Clustering and Hyper-V support Clusters as large as 64 Nodes.

How to Manage your VMs

Depending on the size of your infrastructure you may find that several different tools are available to configure and manage your VMs. These tools all have positive aspects and negative aspects. These tools are discussed below. Additionally, you may find that you use a combination of these tools as they have different uses for different specific needs.

Hyper-V Manager:

This in-box tool is the primary method to create, deploy, and configure your various VMs for small infrastructures. Using this in-box tool, you can configure every aspect of your Physical Servers Hyper-V installation. This tool will show all of the VMs hosted on a physical machine and can be configured to show the VMs from multiple physical machines. This dashboard can give you the most information of any of the tools about the VMs hosted on a specific machine; however, being able to determine where a VM happens to be hosted requires you open the individual dashboards for each Hyper-V host. To manage a Standalone Hyper-V host this tool is the only acceptable method. This tool however has a blind spot in that it doesn’t manage the cluster hosting the virtual machines, and such cannot show all the VMs on a single Cluster. To configure a Machine to run Hyper-V you will do the initial configuration in this tool, and then for each node of a cluster.

Failover Cluster Manager:

This in-box tool  picks up where the Hyper-V manager leaves off, namely, to understand how to host a Virtual Machine on Shared Storage in the Cluster and configure the VM so that it can be migrated from Node-to-Node. Once Hyper-V is configured, you can now use Failover Cluster Manager as your primary method to create, deploy, and configure your various VMs. However, some settings are not available in the Failover Cluster Manager Hyper-V options such as configuring the individual Hyper-V servers vNICs. The real benefit of using Windows Failover Cluster Manager to manage your VMs is that you have an immediate view of ALL the VMs across the cluster, and can initiate failovers and migrations to load balance, and configure some optional replication and reliability features such as Hyper-V Replica. The Failover Cluster Manager can show on a single screen all the VMs and their status on a single screen, but you need to change screens to view VMs hosted on another Cluster. So this tool is the most useful for a single cluster or very few clusters.

System Center Virtual Machine Manager:

This is a separate licensable tool that runs on an external server. This tool is designed to run as a master control panel, which is much closer to the experience you would get  with vSphere And it will give you a single screen where you can manage sets of VMs that span multiple sets of Windows Failover Clusters. This tool is also the tool to use when you want to deploy based on predefined templates, which is a far more manual process on either of the previous tools. SCVMM is very good at deploying and controlling multiple VMs, however you will still need to fail back to the Failover Cluster Tool or the Hyper-V Manager to configure aspects of the Hyper-V platforms that you expect to host these VMs on. The SCVMM tool is both more complex to operate and more capable in the cloud type functions that it offers. Since the conversion process depends on the trial version of SCVMM, you will gain some familiarity with this tool. Adoption of the SCVMM tool will not remove the need to know and use the Hyper-V tool which is required to setup the Hyper-V environment per server, or Failover Cluster Manager which is required to setup the Cluster upon which Hyper-V is hosted.

To get more details on the process to convert your VM from VMWare to Hyper-V, the following guide is a complete walkthrough:

https://learn.microsoft.com/en-us/system-center/vmm/vm-convert-vmware?view=sc-vmm-2025

To get more details using Hyper-V Manager to host and control Virtual Machines on Windows Server, the following guide is a complete walkthrough.

https://learn.microsoft.com/en-us/training/modules/configure-manage-hyper-v-virtual-machines/?source=recommendations

To get more details using Hyper-V Manager to host and control Virtual Machines on Windows Server, the following guide is a complete walkthrough.

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/jj863389(v=ws.11)

Common Misconceptions Running a Hyper-V Cloud

VMware Feature Parity.

People unfamiliar with Hyper-V sometimes claim that Hyper-V is somehow at a feature deficit with the feature set available via ESXi and vSphere. Commonly this belief is due to the nomenclature which Microsoft uses being significantly different. An example of this is the feature called ‘vMotion/Storage vMotion’ which is the Microsoft term for ‘Quick/Live Migration’ in which a VM may be moved from host to host with minimal downtime (quick), or with zero downtime (live), and which also supports the same options for the Storage and Configuration files that make up a VM (Storage Migration). Similar commonalities exist between VMware on NFS and Hyper-V on SMB, or between RDM (Raw Device Mapping) vs Physical Disk, or between VMFS and CSV (Cluster Shared Volumes). In other limitations such as RAM per Node/VM or Cores per Node/VM, Hyper-V commonly exceeds VMware’s capabilities. There are also a class of features that are unique to Hyper-V that may be of interest to customers as well: Shielded VMs. This is where a VM is created and encrypted such that the Hyper-V administrator does not have access to the encrypted hard drive or any back-door type access in the protected VM. You can see a list of these limits here: https://learn.microsoft.com/en-us/windows-server/get-started/locks-limits?tabs=full-comparison&pivots=windows-server-2025

Licensing

The first common misunderstanding is that Hyper-V (or Windows Failover Clustering) is a separate product with separate licensing. This is incorrect as its part of the base OS. There is no additional cost to enable or run Hyper-V or Windows Failover Clustering, with the exception that the VMs that are running will either need their own licensing (Windows Server Standard) or inherit the licensed status of the Hyper-V server in the case of Windows Server DataCenter.

Pay-As-You-Go

If the base OS license is Windows Server 2025, you now have the option to purchase the perpetual license (as always), or the new option of purchasing a pay-as-you-go option. This pay-as-you-go option is available in both Windows Standard Server and Windows Datacenter Server. This option may be of interest to customers who wish to convert a capital expense (CAPEX) into an operation expense (OPEX), of for customers that have a highly elastic or temporary workload. To use this feature you will need to enable the optional Azure Arc feature for OPEX billing following the procedure listed here; https://learn.microsoft.com/en-us/windows-server/get-started/windows-server-pay-as-you-go?tabs=gui%2Cazureportal

Hyper-V is just a hypervisor, not a cloud

Yes, Hyper-V enabled on a single server is only a hypervisor, but when combined with the integration of Windows Failover Cluster for failover, replication, migration, and combined with SCVMM for template-based deployments, elastic controls, and service models, the solution is a capable private cloud by any definition.

What about Automation

All of the features of Windows Server, Hyper-V and Windows Failover Clustering are available as PowerShell modules that allow for complete automation of any action. To Automate actions of SCVMM you would add the System Center Orchestrator product which offers a complete automation/orchestration layer. Since System Center is a suite; there is no extra cost to deploy either System Center Orchestrator or System Center Operations Manager for entire site hardware management/monitoring.

Make the move to HPE hybrid cloud solutions

Along with leading infrastructure products, HPE has a broad range of solutions for Microsoft workloads.  Customers can take advantage of the technical guidance, training and integrations available for running HPE products with Microsoft applications.  Learn more about these products and solutions along with relevant customer examples at HPE.com/Storage/Microsoft