/ EUR
Virtualization entices with simplicity – "throw VMs on the host and it works". In practice it works only when cores, RAM and storage were calculated before you clicked the VMware installation. A server for multi-machine environment is not a "bigger computer". It's a platform meant to carry a dozen, sometimes dozens of systems simultaneously – with different load profiles, different memory appetite and different I/O needs. If you're planning to implement VMware, Proxmox or Hyper-V in your company – start with power.
How much total vCPU do you really need to configure a virtualization server? Before clicking "add second processor", calculate this properly
First calculate the total vCPU of all planned machines, only then select physical cores – reverse order ends in over-sizing or host overload.
- Conservative production start: CPU overcommit 1:1 to 1:2 (vCPU : logical thread).
- Physical server processor 16c/32t provides 32 logical threads which hypervisor distributes among VMs.
- Too high overcommit = rising CPU Ready and VM wait for core access.
- New VMs start from 1-2 vCPU, you increase only after load analysis.
Sounds simple, but this is where the mistake is most often made. You see it regularly: company plans 15 VMs, each "just in case" gets 4 vCPU because "better to have more". Suddenly there's 60 vCPU on a host with 16 cores. Hypervisor scheduler starts juggling threads, CPU Ready appears, applications respond slower, and in vCenter everything "seems" fine. Virtualization doesn't like over-allocation.
Good practice is start small and scale up – minimal allocation, monitoring and then correction. In many SMB environments 1 powerful CPU with 12-16 cores at sensible clock speed comfortably handles a dozen lightweight VMs. Second processor makes sense when machine count grows dynamically or loads like SQL, VDI or analytics systems appear. Calculate first. Expand later.
Cores vs clock speed – why "more" doesn't always mean "better" in VMware environment?
In virtualization it's about balance between core count and single-core performance – core density alone doesn't guarantee better VM operation.
- Hyper-Threading / SMT means 1 core = 2 logical threads, but this doesn't double power.
- Too many idle cores at low clock speed increase scheduler work.
- One VM with 16-32 vCPU can run slower than the same with 4-8 vCPU.
- Topology "Sockets × Cores" matters for NUMA and how guest system sees CPU.
This is where specs stop being obvious. A processor with huge core count looks impressive, but if most of your VMs are application servers, AD, files, monitoring – often more important is stable, higher single-core clock speed. Virtualization distributes load. If one machine needs to sync many threads at once, too high vCPU allocation can… slow it down, because scheduler waits for all logical threads to be free simultaneously.
That's why planning VMware power isn't about "maximum core count". It's about matching cores to real workload profile. Otherwise budget goes into CPU, and real bottleneck turns out to be RAM or storage. And that's a completely different conversation.
Virtualization server configuration: 128, 256 or 512 GB RAM? See how much memory a dozen VMs really "eat"
In practice it's RAM, not CPU, that most often limits the number of virtual machines on a host.
- AD, DNS, small services – 4-8 GB RAM.
- File server, business applications – 8-16 GB RAM.
- Small SQL / ERP – 16-32 GB RAM (more with larger databases).
- Hypervisor usually needs 10-20% RAM for itself.
- Production environments target 1.0-1.3× vRAM vs physical memory.
Host with 128 GB RAM comfortably handles a dozen lightweight VMs without aggressive overcommit. At 256 GB comfort starts – 20-40 machines with mixed profile while maintaining safety margin. 512 GB and more is already dense environments: VDI, several databases, reporting systems.
Memory overcommit is technically supported, but if you overdo it, ballooning, compression and swapping appear. And swapping in production environment means one thing – service latency spikes. That's why experienced admins usually stick close to physical memory with critical systems, treating overcommit as buffer, not foundation.
In short: if you're wondering whether 128 GB suffices, answer one question – how much RAM will your VMs use during peak hours, not at night. This value should determine host configuration. You can still "stretch" CPU. You can't stretch RAM.
NVMe under datastore – when storage becomes the cluster bottleneck?
If VMs start responding slower despite CPU and RAM headroom, storage is almost always the bottleneck – and with many virtual machines random I/O kills it.
- NVMe PCIe 4.0/5.0 – even 1 million+ IOPS, latencies of tens-dozens of µs
- SSD SATA/SAS – usually 100-200k IOPS, latency measured in hundreds of µs
- HDD 10K/15K – latency in few ms and disaster with many concurrent operations
- 4-8 NVMe disks in RAID 10 as local datastore is today sensible production minimum
- SDS (vSAN, Ceph) lets you combine local NVMe into efficient and redundant cluster
In multi-machine environment each VM generates its own small, scattered operations – logs, indexes, system files, snapshots, backups. This isn't sequential large file copying. This is continuous, random traffic. And that's exactly why disk drives, and even some older SSDs, start to "choke".
In practice, 4-8 NVMe in RAID 10 gives not only enormous throughput but also stability during peaks – system updates, snapshots, backups or mass VM startup after host restart. With small 2-3 node clusters, local NVMe + Software-Defined Storage (vSAN / Ceph) model works very well – you get both local disk performance and redundancy between hosts.
EPYC or Xeon Gold? VM density versus single-core and compatibility – choose consciously
Processor platform choice determines how many VMs you can actually fit on one host and how the per-core computational cost will look.
- Dell PowerEdge R7615 (1× AMD EPYC) – up to 128 cores per socket, DDR5 4800 MT/s, PCIe 5.0
- Dell PowerEdge R7625 (2× AMD EPYC) – even greater density, even several TB RAM, aimed at VDI and large clusters
- Xeon Gold – strong single-core performance, very mature ecosystem and compatibility
- EPYC – more memory channels and PCIe lanes = higher RAM and storage throughput
If your goal is maximum VM density on one host and good TCO per thread, EPYC in R7615 / R7625 models today offers huge flexibility. High core count, many memory channels and modern PCIe 5.0 mean you can pack the environment densely without I/O bottlenecks.
On the other hand Xeon Gold is still a very strong option where single-core performance matters and broad compatibility with specific storage or HCI solutions. In some application environments higher single-core clock gives better results than core count alone.
It's not "better-worse" choice. It's: are you building a host for maximum VM density or more classic, balanced loads. That's exactly why CPU topic fits well in the configurator – to see the difference in core count, RAM and NVMe at specific budget.
One host or 2-3 node cluster? If you're thinking HA, start with this decision
Virtualization without high availability works – until first serious host failure.
- 2-node cluster + witness – sensible HA minimum
- 3-node cluster – fuller redundancy and service comfort
- Automatic VM migration (HA / failover) after host loss
- vSAN / Ceph / Storage Spaces Direct – data replication between nodes
- Planned work without downtime capability
Single host is cheaper and simpler. However, if accounting, ERP, CRM or production system run on these VMs, one point of failure is real downtime risk. 2-node cluster with additional witness already lets you build basic HA – if one host fails, VMs start on the other.
3-node cluster offers more flexibility. You can take one node down for service and still maintain redundancy. With local NVMe and SDS you get performance and failure resilience without building elaborate SAN infrastructure.
So if you're planning virtualization "for real", the question isn't whether HA is needed. The question is: what downtime level can you accept? The architecture starts from this answer.
Check your configuration in practice!
Instead of guessing how many cores and NVMe you need, test different options in our server configurator.
Select:
- platform,
- number of cores and threads,
- 128-512 GB RAM and more,
- NVMe configuration for datastore,
- single host or 2-3 node cluster variant.
In a few minutes you'll see how cost and scalability change with different scenarios. If you're unsure – better to verify the design before deployment than after first host overload.
FAQ
Is one host enough for small company?
Yes, if you accept no HA. With critical production systems, at least 2-node cluster is recommended.
Can CPU be heavily overcommitted?
Technically yes, but for production stay with 1:1-1:2 and increase the ratio only after monitoring.
Does RAM or CPU limit host faster?
In most SMB environments, it's RAM that's the first limit, not CPU.
Is NVMe mandatory under VMware?
With a dozen or more VMs – practically yes. Random I/O quickly exposes HDD and older SSD limitations.
EPYC or Xeon Gold – what to choose?
If counting maximum VM density – EPYC. If compatibility and single-core matter more – Xeon Gold. Decision depends on workload profile.
