VMware renewal quote: options for a cluster of three hosts
When a Broadcom renewal quote for three ESXi hosts comes back higher than last year's support bill, and the hosts are due for replacement inside the term, recount the quote from the hosts before pricing any VMware alternative. The host layout sets the Broadcom, Windows Server and Proxmox lines at once, so the host order is a licensing decision that belongs before the signature.
Counting billed cores on today's hosts and the next ones
Broadcom licenses VMware Cloud Foundation (VCF) and VMware vSphere Foundation (VVF) per physical core, with a minimum of 16 cores for every CPU, even when the CPU has fewer. The core counting article, KB 313548, states the rule and ships a PowerCLI function, Get-FoundationCoreAndTiBUsage -DeploymentType VVF, that applies it to every host in vCenter. Redo the quote in three steps:
- For each CPU in each host, take the larger of 16 and its physical core count, then add them up.
- Divide the quote's subscription total by its core quantity to get your rate per core. Broadcom publishes no list price per core, so this rate is the only one that counts.
- Multiply that rate by the billed cores of each layout you might buy next.
Harlan Point Distributors, a hypothetical building supply company with 180 employees, runs 22 VMs on three hosts: 17 Windows servers and 5 Linux appliances. Each host has two CPUs with 10 cores each and four 1.92 TB SSD capacity drives for vSAN. That makes 60 physical cores and 96 billed ones, because every CPU with 10 cores bills as 16. Harlan Point licenses Windows Server Datacenter on every core of every host, so any Windows VM can run on any host.
| Layout for three hosts | Physical cores | Cores left with one host down | Cores Broadcom bills | Windows Server core licenses | Proxmox Standard per year |
|---|---|---|---|---|---|
| Today: 2 CPUs of 10 cores | 60 | 40 | 96 | 60 | EUR 3,300 (6 sockets) |
| 1 CPU of 16 cores | 48 | 32 | 48, or 72 under an order minimum | 48 | EUR 1,650 (3 sockets) |
| 2 CPUs of 16 cores | 96 | 64 | 96 | 96 | EUR 3,300 (6 sockets) |
Windows Server also licenses every physical core, with a floor of 8 core licenses per processor and 16 per server. Proxmox bills its Standard subscription at EUR 550 per socket per year.
Hosts with two CPUs of 16 cores keep the Broadcom count at 96 and add 36 Windows Server core licenses. At the Datacenter list price of $6,771 per 16 cores, those 36 cost about $15,235. That figure assumes today's 60 licenses move to the new hosts. Microsoft lets a license be reassigned to new hardware once it has sat on a server for 90 days, which licenses bought years ago already have. Licenses that shipped with the old servers may be tied to that hardware, so check how yours were bought before counting them.
Hosts with one CPU of 16 cores halve the Broadcom line and the Proxmox sockets, and they need no new Windows licenses. The cost is headroom. With a host down, 32 cores carry the load that 40 carry today, so pull a month of peak CPU demand per host from the vCenter performance charts and check that two hosts can absorb it. A single socket also halves the memory channels and DIMM slots, so confirm that each host can still hold the RAM it needs when it carries half of the third host's VMs.
The vSAN entitlement moves with the core count. VVF includes 0.25 TiB of vSAN per billed core, rounded up to the next TiB, and VCF includes 1 TiB. Broadcom counts raw physical capacity across every host that contributes to vSAN, and the Capacity Overview tab in vCenter shows datastore capacity, which is a different number. Harlan Point's 12 drives come to about 21 TiB raw. Its 96 VVF cores cover 24 TiB. At 48 cores the entitlement drops to 12 TiB, and the remaining 9 TiB becomes an add-on line on the quote.
Which work stays with your team on each path?
The alternatives worth pricing differ most in the work they leave with your staff: the hosts, the patching, the next refresh, the conversion, and the license lines that stay on your side.
| Path | Your team still owns | Who converts the VMs | License lines left on your side | Fits when |
|---|---|---|---|---|
| Renew with Broadcom | Hosts, vSphere, patching, the refresh | No conversion | VVF or VCF per billed core, plus any vSAN add-on; Windows Server per host core | Hosts have years of support left, or backups and failover depend on vSphere features |
| Proxmox or Hyper-V on your hosts | Hosts, hypervisor, storage design, patching, the refresh, the conversion | Your staff or a contractor | Windows Server per host core; Proxmox per socket if you buy support | Someone on staff can run the platform and finish the conversions before the anniversary date |
| Hosted VMware at a hyperscaler | The VMs and a VCF subscription | No guest conversion | VCF bought from Broadcom; node charges | The company already runs most of its systems in that cloud |
| Native VMs at a hyperscaler | The VMs as cloud instances, and their sizing | Your staff or a partner, with the cloud's migration tool | Set by the cloud's terms | The business needs more than one region, or demand swings through the month |
| Managed private cloud | Applications, data, users, vendor relationships | The provider's engineers | Whatever the proposal lists; confirm who supplies Windows Server licenses | Nobody wants to run hosts again, and one region is enough |
The refresh arithmetic above applies only to the first two rows. On the other three, the hosts belong to someone else.
Every path except renewal needs each VM recorded and tested before cutover, so the calendar decides as much as the price. A conversion that cannot finish before the anniversary date argues for a short renewal. When a customer's dates make a conversion unrealistic, our engineers say so and explain why.
When staying on vSphere wins
Sign the renewal when one of these holds:
- The hosts have years of hardware support left, and the next refresh falls outside the subscription term.
- Backups, failover or storage depend on vSphere features. Free ESXi 8.0 Update 3e is available again, and it cannot run this cluster: it has no Broadcom support, cannot be managed by vCenter, stops at 8 vCPUs per VM, exposes a read-only API, and lacks vMotion, DRS, HA and VADP backups. Harlan Point's ERP database server, ERP-SQL01, runs 12 vCPUs and would not fit.
- The conversions cannot be tested and finished before the anniversary date.
- A line-of-business vendor supports its product only on VMware.
Check the version first. vSphere 7 left general support on October 2, 2025. A cluster on 7 that renews needs the upgrade to 8 early in the term. Leaving VMware needs no upgrade first, since the Proxmox importer is tested from ESXi 6.5 and the Windows Admin Center extension reads vCenter 6.x. vSphere 8 general support ends in October 2027, and end of technical guidance for ESXi and vCenter 8.0 follows on October 11, 2029. A three-year term signed now runs past October 2027, so the renewal plan has to include the upgrade to vSphere 9 inside the term. vCenter 9.0 drops the baseline workflows in vSphere Lifecycle Manager, so a cluster still patched from baselines moves to image-based management before that upgrade.
Letting a perpetual license lapse works as a bridge of weeks. After support expires, hosts, vCenter, VMs and vMotion all keep working. Patch downloads need an active subscription, with one exception: Broadcom releases patches for critical alerts rated CVSS 9.0 or higher to every vSphere 8 customer. Adding a host or upgrading to a new major version needs the subscription back, so the replacement hosts cannot join the cluster during the gap.
A costed alternative from the two tables above is your strongest position with the reseller. Ask for three answers in writing: which rule set the core quantity, whether renewing after the anniversary date adds a surcharge, and which term lengths are on offer.
Renewing buys time at the quoted rate and leaves the host refresh decision untouched. If the only way to leave VMware before the anniversary date is to skip the test conversions described below, sign the shortest term on offer and convert afterward.
Proxmox and Hyper-V, run by your own staff
Windows Server licensing stays the same under any hypervisor. Datacenter covers unlimited Windows VMs on those cores and includes the Hyper-V role, so a cluster already licensed for Datacenter adds no license cost by switching to Hyper-V.
vSAN does not carry over to either platform, so the hosts need a new storage design (Storage Spaces Direct, Ceph, or a SAN) before the first conversion.
On Hyper-V, the hyperconverged choice is Storage Spaces Direct, which Datacenter includes. It needs drives attached through a pass-through HBA, at least 10 Gbps between nodes for a cluster of two or three, and at least four capacity drives per server in an all-flash build. Harlan Point's four drives per host meet that floor exactly. The other choice is a SAN over iSCSI or Fibre Channel.
Automatic VM Activation (AVMA) activates Windows guests from a Datacenter host with the Hyper-V role, and it works on no other virtualization platform. The Windows Admin Center VM Conversion extension handles the conversion. Microsoft still labels it a preview and carries no support obligation for it. It reads vCenter 6.x, 7.x and 8.x and converts VMs in batches of up to 10. Each conversion snapshots the running source, copies the disks, then powers the source off for a final delta sync through Changed Block Tracking. Static IP settings carry over, and VMware Tools come off Windows guests afterward. The supported guest list starts at Windows Server 2012 R2, so an older guest needs another route, and Linux guests need Hyper-V drivers installed beforehand so they boot on the other side.
Proxmox VE, currently at release 9.2, bills subscriptions per CPU socket per year at EUR 120, 370, 550 or 1,100, with every feature included at every level. For a VMware to Proxmox migration, the ESXi importer built into Proxmox needs Proxmox VE 8 or later and is tested against ESXi 6.5 through 8.0. Point it at each ESXi host, since importing through vCenter is dramatically slower. It cannot import disks stored on vSAN or encrypted disks, it slows down sharply when a VM has snapshots, and a live import that fails loses everything written since it started. Harlan Point's VMs sit on vSAN, so each one needs a Storage vMotion to a temporary NFS or VMFS datastore with room for it before the importer can read it.
Proxmox also changes what goes on the host order:
- High availability needs three nodes, or two nodes plus a QDevice for quorum. Corosync wants latency under 5 ms and its own network interface.
- Hyperconverged Ceph needs at least three servers, preferably identical, with at least 10 Gbps of network reserved for Ceph and HBAs in place of RAID controllers. Hosts ordered with RAID controllers cannot serve Ceph as built.
- Shared LVM on an iSCSI or Fibre Channel LUN works, though VM snapshots on it remain a technology preview.
Whichever hypervisor wins, your staff patches and upgrades it from then on, major versions included. Skip this path when nobody on staff has run Linux hosts or Windows failover clustering, when a vendor's support matrix lists only VMware, or when the conversions cannot finish before the anniversary date.
Hosted VMware at a hyperscaler still needs your own VCF subscription.
Moving the cluster to a hyperscaler as it stands keeps Broadcom on the bill. Azure VMware Solution requires a portable VCF subscription from Broadcom, with a minimum first purchase of three nodes. Amazon EVS runs on VCF licenses bought from Broadcom or a qualified reseller, with EC2 bare metal billed at standard rates plus an hourly control plane charge per instance. A cluster quoted today for VVF would have to buy VCF, the larger bundle, to take either route.
Getting Broadcom off the bill at a hyperscaler means converting the VMs to native instances. AWS Transform MGN, the renamed Application Migration Service, replicates VMs into EC2 and bills the infrastructure it provisions for replication, testing and cutover. That route suits a business that needs more than one region or whose demand swings. Price steady VMs that run all month in the cloud's own calculator before committing to it.
Private cloud, run by the engineers who answer your call
This path hands the hosts and the platform under the VMs to a provider. Your team keeps the applications, the data, the users and the vendor relationships, and the next host refresh becomes the provider's purchase.
Petrichor runs this path on our own hardware. We built it to run Windows and Linux business applications that were never designed for a cloud.
Our engineers do the cloud migration. They design the target environment, walk your team through it, and test it repeatedly with your own people before cutover. Production does not go first. We start with a development or test copy, and a request to hand over production on the first day gets slowed down until we know how your environment behaves.
After cutover, your team files a ticket for database work, a backup or a restore, and one of our engineers does it. Customers know the names and phone numbers of the people who pick up.
Everything runs in one data center. A business that needs several regions belongs at a hyperscaler, and geo redundancy here is a paid option.
MAC, BIOS UUID, static IP and license contacts for each VM
A conversion changes the machine identity that DHCP reservations, license servers and Active Directory rely on. Record that identity for each VM before cutover, or the first morning on the new platform becomes a queue of vendor tickets.
| Step | How | What breaks if skipped |
|---|---|---|
| Export the inventory | RVTools, free from Dell, version 4.8.2: the vInfo, vNetwork and vDisk tabs | Nothing to check disks, NICs, MACs, snapshots or Tools versions against after conversion |
| Delete or consolidate snapshots | vCenter, for each VM | The Proxmox importer runs much slower on VMs with snapshots |
| Record each NIC's MAC | RVTools vNetwork tab | DHCP reservations and license servers bound to the MAC stop matching |
| Record the BIOS UUID | uuid.bios in the VM's .vmx file, plus (Get-CimInstance Win32_ComputerSystemProduct).UUID inside the guest | License servers bound to the UUID reject the converted VM |
| Record static IP, mask, gateway and DNS for each NIC | ipconfig /all saved inside the guest | The new adapter gets a new name, and Windows warns that the address belongs to another adapter |
| List vendor license contacts | Name, portal and phone number for every application that activates | A reissue requested after cutover leaves the application down until the vendor answers |
| Remove VMware Tools | Uninstall before converting to Proxmox; the Windows Admin Center extension removes it on Hyper-V | Tools are hard to remove once the VM runs on another hypervisor |
| Stage storage drivers | On Proxmox, boot Windows on SATA, add a 1 GB VirtIO SCSI disk, install the driver from the VirtIO ISO, then move the boot disk to VirtIO SCSI single | Windows cannot boot from a VirtIO disk it has no driver for |
| Replace domain controllers | Promote a new DC on the target, move the FSMO roles, demote the old one | A converted DC sees a new VM-GenerationID, resets its invocation ID and discards its RID pool |
| Reactivate Windows | AVMA on Datacenter Hyper-V hosts; your current activation method elsewhere | Windows can drop out of activation when the virtual hardware changes |
| Keep the source VM | Powered off and untouched until the cutover is signed off | The rollback path disappears |
On Proxmox, the identity crosses over with two commands. For Harlan Point's license server, LIC01, once VM 131 exists:
qm disk import 131 LIC01.vmdk local-lvm
qm set 131 --net0 virtio=00:50:56:9a:3c:1f,bridge=vmbr0 --smbios1 uuid=4211c5e2-7a3b-9d10-5e6f-0a1b2c3d4e5fThe imported disk arrives unattached, so attach it on SATA for the first boot and swap to VirtIO after the driver is in. After first boot, run the same Get-CimInstance query inside the guest and compare it with the value recorded under VMware. If the first three groups come back in reversed byte order, pass the guest's recorded value to --smbios1 and boot again, because the license server reads what the guest reports. On Hyper-V, the Windows Admin Center documentation lists static IP preservation and says nothing about MAC addresses or BIOS UUIDs. Record both anyway and compare them after each conversion.
Convert ERP-SQL01 and LIC01 first, on an isolated VLAN
Pick the two VMs the business cannot run without and treat them as the first migration rehearsal. At Harlan Point, those are ERP-SQL01 and LIC01, the license server for its estimating software. Convert copies of both, carrying the identity recorded above, onto a VLAN with no route to production, because the preserved MACs, UUIDs and addresses would collide with the live VMs. Keep every copy of a production domain controller away from any network that reaches production. A DC copy booted without clone preparation has to come off the network as soon as possible.
The test passes when LIC01 hands out a seat, a user logs into the ERP, posts one transaction and runs one report, and the overnight job completes once.
Time every step on the two largest disks: the Storage vMotion off vSAN, disk import, driver swap, first boot. Those times set the cutover window. The extension's final delta sync shortens it on Hyper-V. On Proxmox, a live import shortens it and carries the data loss risk described above.
Rollback has a limit. Powering the untouched source back on works only until users write data to the converted VM, and after that point every change they made has to be carried back by hand.
List your VMs in the workload sizing sheet and book a call with a consultant before the renewal date.