Data Center Virtualization in Practice

From single hosts to a cluster

The basics of hypervisors, virtual machines (VMs) and snapshots are covered in Virtualization and Hypervisors. On one host, virtualization saves hardware but makes that host a single point of failure for every VM on it. Data centers therefore group hosts.

A virtualization cluster is a group of hypervisor hosts that are managed as one pool of compute capacity. All hosts in the cluster see the same shared storage and the same virtual networks, so a VM is not tied to the host it happens to run on. That single property enables everything else on this page: moving running VMs for maintenance, restarting them after a host failure, and spreading load automatically.

A typical cluster has 3 to 32 identical hosts. Identical matters: the same CPU generation, memory size, network cards and firmware make every host a valid target for every VM.

The main platforms

Four families cover most on-premises data centers in 2026. All of them use a type 1 hypervisor; they differ in management tools, storage integration and price.

VMware vSphere

vSphere is the hypervisor plus its management layer. The hypervisor is called ESXi up to version 8 and, from version 9.0 (June 2025), ESX again; many people still say ESXi out of habit. vCenter Server is VMware's central management server: a virtual appliance that manages many ESX/ESXi hosts, groups them into clusters, and provides the cluster features on this page (live migration with vMotion, vSphere HA, DRS load balancing, distributed switches, templates). Without vCenter, each host is managed on its own.

vSphere HA keeps restarting VMs even while vCenter is down (an agent on each host does the work), but configuration changes, DRS and vMotion need vCenter. Protect and back up vCenter like the critical system it is.

Microsoft Hyper-V

Hyper-V is part of Windows Server. Hosts are clustered with Windows Server Failover Clustering, and shared storage is presented to all hosts as Cluster Shared Volumes (CSV). Management is done with Failover Cluster Manager, Windows Admin Center, PowerShell, or System Center Virtual Machine Manager (SCVMM) for large estates. In Windows Server 2025, a generation 2 VM can have up to 2,048 virtual CPUs and 240 TB of memory. Microsoft's hyperconverged offer, formerly Azure Stack HCI, is now called Azure Local (see HCI platforms).

Proxmox VE

Proxmox VE (Virtual Environment) is an open-source virtualization platform based on Debian Linux. It runs VMs with KVM and QEMU and Linux containers (LXC), and includes clustering, high availability, built-in Ceph storage and backup integration, all managed through a web interface on every node, so there is no separate management server. As of October 2026 the current release is Proxmox VE 9.2 (May 2026: Debian 13, Linux kernel 7.0, QEMU 11.0), with an official Arm64 build since August 2026. Many organizations evaluated it as an alternative after VMware's licensing changes.

A Proxmox cluster uses Corosync for membership and needs a majority of votes (quorum) to make changes. pvecm status (Proxmox VE cluster manager) shows it:

Cluster information
-------------------
Name:             kestrel-pve
Config Version:   7
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Thu Oct  1 09:14:02 2026
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2c
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   3
Highest expected: 3
Total votes:      3
Quorum:           2
Flags:            Quorate

Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 192.0.2.21 (local)
0x00000002          1 192.0.2.22
0x00000003          1 192.0.2.23

Three nodes with one vote each need two votes for quorum: one node may fail. A two-node cluster loses quorum when either node fails, which is why two-node setups add an external vote (a "QDevice" in Proxmox, a witness in other platforms; see Disaster Recovery and Site Resilience).

KVM, Nutanix and OpenStack

KVM (Kernel-based Virtual Machine) is the Linux kernel's hypervisor module; QEMU emulates the virtual hardware. Together they run under Proxmox VE, Nutanix AHV, OpenStack and most public clouds. On a single Linux host they are managed with libvirt and virsh; at scale, a platform such as OpenStack or Nutanix adds the cluster features.

Shared storage and virtual networking

Shared datastores

Each platform stores VM disks as files or volumes on storage all hosts can reach. VMware calls this a datastore: a VMFS file system on a block LUN (Fibre Channel, iSCSI or NVMe over Fabrics), an NFS share, or a vSAN datastore. Hyper-V uses Cluster Shared Volumes or SMB 3 file shares; Proxmox uses Ceph RBD, NFS, iSCSI or ZFS with replication. The storage side is explained in DAS, NAS and SAN, SAN Protocols and Software-Defined Storage and Hyperconverged Infrastructure.

Virtual switches

A virtual switch is a software Ethernet switch inside the hypervisor. VMs connect to it with virtual network cards (vNICs), and it connects to the physical network through the host's real network cards, its uplinks. It learns MAC addresses and handles VLAN tags like a physical switch.

• VMware: a standard switch (vSS) is configured per host; a distributed switch (vDS) is configured once in vCenter and applied to every host in the cluster, which prevents "the VLAN exists on four hosts but not the fifth". VMs connect to port groups, typically one per VLAN.
• Hyper-V: an external virtual switch is bound to a physical NIC (network interface card) and reaches the real network; internal connects VMs and the host only; private connects VMs to each other only.
• Proxmox VE and KVM: a Linux bridge (by default vmbr0) or Open vSwitch, optionally with the SDN (software-defined networking) features for VLAN, VXLAN and EVPN zones.

In a data center, VMs are bridged: the virtual switch puts them directly on a physical VLAN, so they have real addresses on the network. NAT mode, where the host translates the VM's addresses, is common on desktop hypervisors but rare on servers. Uplinks are always at least two NICs, connected to two different physical switches and set up as a team (failover or link aggregation), so a cable or switch failure does not cut off the VMs.

Separate traffic types

A host carries several kinds of traffic that should not disturb each other. Common practice is a separate VLAN (and often separate NICs) for each:

The physical side of this, two switches per rack and redundant uplinks, is covered in Data Center Networking; the host's own management controller belongs on the separate network described in Out-of-Band Management.

Live migration

Live migration moves a running VM from one host to another without shutting it down. Users notice at most a brief pause. VMware calls it vMotion, Hyper-V and Proxmox call it live migration. Its main use is planned work: empty a host before patching or replacing it, then move the VMs back.

How it works

1. The destination host creates an empty copy of the VM.
2. The source copies all of the VM's memory over the migration network while the VM keeps running (pre-copy).
3. Memory pages the VM changed during that copy ("dirty" pages) are sent again, round after round, each round smaller than the last.
4. When the remainder is small enough, the VM is paused for a fraction of a second, the last pages and the CPU state are sent, and the VM resumes on the destination.
5. The destination announces the VM's MAC address on the network so the physical switches update their MAC address tables.

The disks do not move, because both hosts see the same shared storage. Moving the disks too is a separate, slower operation (Storage vMotion, storage migration).

Pre-copy only finishes if the network copies memory faster than the VM changes it. The model below shows this for a 64 GB VM; it is pessimistic (real VMs rewrite the same hot pages, so dirty memory levels off), but the trend is real.

PAUSE_TARGET_S = 0.1   # switch over when the rest fits in this pause
MAX_ROUNDS = 30


def migrate(memory_gb, dirty_gb_per_s, link_gbit):
    speed = link_gbit / 8 * 0.9          # GB/s, minus about 10% protocol overhead
    to_send, total_s = memory_gb, 0.0
    for round_no in range(1, MAX_ROUNDS + 1):
        seconds = to_send / speed
        total_s += seconds
        # pages the VM changed while this round was copied must be sent again
        to_send = min(memory_gb, dirty_gb_per_s * seconds)
        if to_send / speed <= PAUSE_TARGET_S:
            pause_ms = to_send / speed * 1000
            return f"done after {round_no} rounds, {total_s:.0f} s, final pause {pause_ms:.0f} ms"
    return f"no convergence after {MAX_ROUNDS} rounds: still {to_send:.1f} GB dirty"


for memory_gb, dirty, link in [(64, 0.2, 10), (64, 0.9, 10), (64, 1.5, 10), (64, 1.5, 25)]:
    print(f"{memory_gb} GB VM, dirties {dirty} GB/s, {link} Gbit/s link: {migrate(memory_gb, dirty, link)}")

64 GB VM, dirties 0.2 GB/s, 10 Gbit/s link: done after 4 rounds, 69 s, final pause 57 ms
64 GB VM, dirties 0.9 GB/s, 10 Gbit/s link: done after 29 rounds, 284 s, final pause 88 ms
64 GB VM, dirties 1.5 GB/s, 10 Gbit/s link: no convergence after 30 rounds: still 64.0 GB dirty
64 GB VM, dirties 1.5 GB/s, 25 Gbit/s link: done after 9 rounds, 49 s, final pause 79 ms

A busy database VM on a 10 Gbit/s migration network may never converge; on 25 Gbit/s the same VM moves in under a minute. Real hypervisors help a stuck migration by briefly slowing the VM's virtual CPUs so it dirties memory more slowly (VMware and QEMU both do this), but a fast, dedicated migration network is the real fix.

Requirements and common failures

• Same networks on both hosts. If the VM's VLAN or port group is missing on the destination, the migration is refused (or, worse, the VM arrives without network).
• Compatible CPUs. A running guest has already detected its CPU features. VMware's EVC (Enhanced vMotion Compatibility), Hyper-V's processor compatibility mode and Proxmox's generic CPU types hide newer features so that VMs can move between CPU generations. A Proxmox VM set to CPU type host can only move between identical CPUs.
• Shared storage reachable from both hosts, and no local-only devices attached, such as a mounted ISO file on a host's local disk or a USB device passed through.
• Enough free memory on the destination.

VM high availability

VM high availability (HA) is a cluster feature that detects a failed host and automatically restarts its VMs on the surviving hosts. It is a restart, not a move: the VMs crash with their host, so users see an outage of a few minutes while the VMs boot and their applications start, and anything that was only in memory is lost. It turns "down until someone replaces the server" into "down for five minutes" at no cost per VM. For general concepts, see High Availability and Disaster Recovery.

Detecting a failed host

Hosts exchange heartbeats, small "I am alive" messages, over the management network (and in vSphere also through the shared datastores). When a host stops answering, the cluster must tell two situations apart: the host is dead, or only its network is cut and its VMs are still running. Restarting a VM that is still running elsewhere would put two copies on the same disks, so platforms use a second channel (datastore heartbeats, a quorum, or fencing that powers the host off through its management controller) before they restart anything. An isolated host in turn shuts down or keeps its VMs according to the isolation response you configure.

Set restart priorities: domain controllers and DNS first, then databases, then the application servers that depend on them.

Admission control: keeping room for a failure

HA can only restart VMs where there is free capacity. Admission control reserves that capacity, usually by refusing to power on new VMs once the cluster could no longer absorb the loss of one host (N+1). A percentage reservation is not quite enough, though: the free memory is spread over several hosts, and a large VM needs one host with a gap big enough for it. The example checks a four-host cluster.

HOST_GIB = 384  # memory per host available to VMs
placement = {
    "esx01": {"sql01": 128, "sql02": 128, "app01": 32, "app02": 32},
    "esx02": {"billing01": 96, "billing02": 96, "web01": 16, "web02": 16},
    "esx03": {"erp01": 192, "mon01": 32, "web03": 16, "dc01": 8},
    "esx04": {"erp02": 192, "app03": 32, "dc02": 8, "jump01": 8},
}

hosts = len(placement)
used = sum(sum(vms.values()) for vms in placement.values())
print(f"Cluster: {hosts} hosts x {HOST_GIB} GiB, VMs use {used} GiB ({used / (hosts * HOST_GIB):.0%})")
spare = (hosts - 1) * HOST_GIB
print(f"N+1 check: {used} GiB must fit in {hosts - 1} hosts = {spare} GiB -> {'ok' if used <= spare else 'FAIL'}")
print()

for failed, lost_vms in placement.items():
    free = {h: HOST_GIB - sum(vms.values()) for h, vms in placement.items() if h != failed}
    restarted, stranded = [], []
    for vm, gib in sorted(lost_vms.items(), key=lambda item: -item[1]):  # largest first
        target = max(sorted(free), key=lambda h: free[h])  # host with most free memory
        if free[target] >= gib:
            free[target] -= gib
            restarted.append(vm)
        else:
            stranded.append(f"{vm} ({gib} GiB, largest gap {free[target]} GiB)")
    line = f"{failed} fails: restarted {', '.join(restarted)}"
    if stranded:
        line += f"; NOT restarted: {', '.join(stranded)}"
    print(line)

Cluster: 4 hosts x 384 GiB, VMs use 1032 GiB (67%)
N+1 check: 1032 GiB must fit in 3 hosts = 1152 GiB -> ok

esx01 fails: restarted sql01, sql02, app01, app02
esx02 fails: restarted billing01, billing02, web01, web02
esx03 fails: restarted mon01, web03, dc01; NOT restarted: erp01 (192 GiB, largest gap 160 GiB)
esx04 fails: restarted app03, dc02, jump01; NOT restarted: erp02 (192 GiB, largest gap 160 GiB)

The cluster passes the simple N+1 check, yet losing esx03 or esx04 leaves an ERP server down: 360–368 GiB is free in total, but no single host has 192 GiB. With DRS enabled, vSphere HA can ask DRS to move other VMs and make room, which takes time; without it, the VM stays off until someone intervenes. Fixes: larger hosts, a fifth host, or smaller VMs, and a policy that sizes the reservation for the largest VM rather than the average.

When a restart is too slow

vSphere Fault Tolerance (FT) keeps a second copy of a VM running in lockstep on another host; if the first host fails, the copy takes over with no restart. It costs double the CPU and memory and has strict limits, so it is used for a handful of small, critical VMs. Most applications get better protection from running two or more VMs behind a load balancer or with application-level clustering, which also survives a crash inside the guest.

Balancing load and sharing resources

Automatic load balancing

Distributed Resource Scheduler (DRS) is the vSphere feature that places VMs on hosts at power-on and, during operation, uses live migration to move VMs from busy hosts to quieter ones. Other platforms have the same idea under different names: Dynamic Optimization in SCVMM for Hyper-V, and since Proxmox VE 9.2 a dynamic load balancer for HA-managed guests. DRS can run fully automated or only make recommendations an administrator approves.

Load balancing respects rules you define:

• Anti-affinity: keep VMs apart. The two domain controllers, the two nodes of a database cluster or the two firewalls must never share a host, or one host failure takes out both.
• Affinity: keep VMs together, for example an application server and its cache that talk constantly.
• VM-to-host rules: keep VMs on certain hosts, usually because of software licensing tied to those hosts.

Maintenance mode uses the same machinery: put a host in maintenance mode and the cluster migrates all its VMs away, after which the host can be patched or powered off safely.

Overcommitment in a cluster

Resource overcommitment means giving VMs more virtual CPUs or memory in total than the hosts physically have, betting that they will not all use it at once. The ratios and the host-level mechanics (CPU ready time, memory ballooning, swapping) are explained in Resource overcommitment. In a cluster, two things change:

• Plan ratios for the failure case. A 4:1 vCPU ratio across four hosts becomes about 5.3:1 on three hosts after one fails. Memory overcommitment that is harmless on a healthy cluster can turn into heavy swapping during an HA event, exactly when you need the VMs to perform.
• Use reservations, limits and shares deliberately. A reservation guarantees a VM a minimum of CPU or memory; a limit caps it; shares decide who wins when resources run short. Reservations also count against HA admission control, so reserve only for VMs that truly need it.

Templates and provisioning

A VM template is a master copy of a prepared virtual machine (operating system installed, patched, agents and settings in place) that cannot be powered on itself and is only used to create new VMs. Deploying from a template takes minutes instead of an afternoon and gives every server the same baseline. Clones and templates in general are introduced in Snapshots, clones and templates.

Each new VM must get its own identity: Windows templates are generalized with Sysprep (otherwise every clone has the same security identifier, which breaks domain membership), Linux templates use cloud-init to set the host name, network and SSH keys at first boot. Treat templates as a product with an owner: update them monthly, or every new VM starts life months behind on patches. At scale, templates are combined with automation (for example Terraform or Ansible) so that VMs are described as code; see Infrastructure as Code and, for building templates by code and first-boot setup with cloud-init, Images and Bootstrapping.

VMware licensing after Broadcom

Broadcom completed its acquisition of VMware in November 2023 and changed the licensing model quickly. Much of what older courses and forum posts say is no longer true. As of October 2026:

• Subscription only. New perpetual licenses and renewals of support for them ended on 11 December 2023. Existing perpetual licenses remain valid but receive no new support.
• Two main bundles. VMware Cloud Foundation (VCF) is the full private-cloud stack; VMware vSphere Foundation (VVF) is the smaller bundle. vSphere 9 features are only available inside these bundles; the standalone vSphere Standard and Enterprise Plus editions stop at 8.0 Update 3. Broadcom has signaled that a smaller vSphere offer may return, but as of October 2026 that is a direction, not a product.
• Per core. Licenses are counted per physical CPU core with a minimum of 16 cores per CPU. A server with two 12-core CPUs is therefore billed as 32 cores. Minimum order sizes have changed several times; check current terms with a reseller.
• Versions. VCF 9.0 was released in June 2025, 9.1 in May 2026 and 9.1.1 in September 2026. vSphere 8 is scheduled to reach end of general support in October 2027.
• Free hypervisor. The free ESXi edition was withdrawn in February 2024 and returned with ESXi 8.0 Update 3e (April 2025): no support, no vCenter, at most 8 vCPUs per VM. No free ESX 9 has been announced.

For comparison: Windows Server Datacenter edition is also licensed per core and allows unlimited Windows Server VMs on the licensed host, Standard edition allows two; Proxmox VE is free to use, with optional paid support subscriptions. A platform change is a large project (migrating VMs, retraining staff, replacing backup and monitoring integrations), so it goes through change enablement like any major change.