Virtualization Dedicated Server

A virtualization dedicated server is the machine you use to run your own private cloud: a single physical box, entirely yours, hosting a fleet of virtual machines and containers under a hypervisor. Instead of renting individual virtual machines from a public cloud, you rent or own the whole server, install a hypervisor, and carve it into as many virtual environments as the hardware sensibly supports — with full control of density, performance, and cost. This page is the practical guide to doing that well: choosing the hypervisor, sizing how many VMs actually fit by the overcommit rules that govern density, planning for a node failing rather than only for a normal day, deciding between containers and full VMs, and picking the hardware that virtualization specifically needs.

What is a virtualization dedicated server?

A virtualization dedicated server is a single-tenant machine that runs a hypervisor — Proxmox, VMware ESXi, KVM, or Hyper-V — so you can create and manage many virtual machines or containers on one physical box. Because the whole machine is yours, all its CPU, memory, storage, and network go to your virtual fleet with no noisy neighbors, and you have full root access and usually IPMI to install the hypervisor you prefer and control the hardware remotely. It is, in effect, a private cloud on hardware you control.

The common uses are building a private cloud for an organization’s internal systems, running a VPS business by selling isolated virtual machines from one box, creating dev and test environments, and consolidating several workloads onto fewer machines. The appeal over public-cloud virtual machines is control and total cost of ownership — for steady, long-term workloads, running your own hypervisor on dedicated hardware is usually cheaper than renting equivalent cloud instances, which is part of why so many organizations are moving workloads back from public cloud to private infrastructure. The trade is that you operate it, or have it managed, because a private cloud is real infrastructure rather than a rented convenience. Where our enterprise dedicated server page covers consolidation strategy at scale, this one is the practical build guide for a host or a small cluster.

Which hypervisor should you run?

The hypervisor is the first decision, and for most teams in 2026 the answer is Proxmox VE. It is free and open-source, built on Debian, and runs both KVM full virtual machines and lightweight LXC containers from one web interface, with high-availability clustering, live migration, ZFS and Ceph storage, and a deduplicating backup server included at no licence cost. That covers what most teams used VMware for, without the licence — which matters more since Broadcom moved VMware to per-core subscription pricing that raised costs sharply. The table sets out the realistic options.

VMware ESXi stays valid where you already depend on its ecosystem and mature third-party integrations, and its raw performance sits within a percent or two of Proxmox. Hyper-V is the natural fit for an overwhelmingly Windows estate, since it comes with Windows Server licensing at no extra hypervisor cost, though Linux guests are second-class next to KVM. KVM with libvirt suits teams that prefer maximum flexibility and infrastructure-as-code over an integrated GUI. The honest short version is to start with Proxmox unless a specific commitment or a Windows-heavy fleet points elsewhere — and to know that whichever you pick, the hardware and sizing principles below are much the same.

VM density: how many fit?

The question of how many virtual machines a server holds has a firm governing rule: CPU can be overcommitted safely, memory cannot. Because most VMs do not use all their assigned CPU at once, you can allocate more total virtual CPUs than the host has physical threads — two to three virtual CPUs per thread is a common safe range for mixed workloads, so a 32-core, 64-thread host can present well over a hundred virtual CPUs. Memory is the opposite: overcommitting RAM is dangerous, because when physical memory is exhausted the system’s out-of-memory process kills virtual machines without warning, so you plan RAM at roughly one-to-one and treat it as the binding constraint. The terminal captures the rules.

# virtualization host · density by the overcommit rules · mcsnet
# example: 32 cores / 64 threads, 256 GB ECC RAM
cpu_overcommit = 2:1 to 3:1 is safe    # approx 128-192 vCPUs across VMs
mem_overcommit = 1:1, do NOT exceed    # OOM killer terminates VMs, no warning
host_reserve   = approx 20% CPU, 16-24 GB RAM  # hypervisor + storage cache
density        = 30-50 small VMs OR 5-10 large # RAM is the binding limit
vm_disks       = NVMe, thin-provisioned # space allocated on demand
zfs_ceph_disks = HBA in IT mode         # raw disks, not hardware RAID
cluster_net    = separate NIC for corosync # heartbeat off the storage link

You also reserve headroom for the host: around twenty percent of CPU and sixteen to twenty-four gigabytes of RAM for the hypervisor, storage caching, and management. In practice a 32-core machine with 256 GB of RAM runs perhaps thirty to fifty small VMs of one to two virtual CPUs and four to eight gigabytes each, or five to ten large ones, with the count set by how much memory each workload really needs. The common mistake is sizing by CPU and forgetting that RAM runs out first — count the memory, keep it near one-to-one, and the VM count falls out of that.

Size for the failure case, not the busy day

The most overlooked part of building a cluster is planning for a node to fail. High availability restarts the virtual machines from a failed host onto the surviving nodes, but that only works if those nodes have enough spare capacity — especially memory — to take on the extra load. Build a three-node cluster and run all three at ninety percent utilization, and you have a cluster that looks highly available but is not: lose one node and the other two cannot absorb its VMs, so the availability you paid for turns out to be theoretical.

The right sizing question, then, is not how many virtual machines the cluster can run, but how many it can keep running after losing a node while still serving. In practice that means keeping a node’s worth of spare capacity distributed across the cluster, running comfortably below full utilization so a failure is absorbed rather than cascaded into an outage. This failure-first thinking is what separates a real private cloud from a collection of busy machines that happen to be clustered, and it is why capacity needs continuous review as workloads grow — an environment that began with ten VMs and drifted to a hundred has almost certainly eaten the headroom that made its high availability real.

Containers or full VMs?

A platform like Proxmox runs both containers and full virtual machines, and the choice between them for a given workload comes down to isolation against efficiency. Containers — LXC on Proxmox — share the host’s kernel instead of running a full guest operating system, which makes them dramatically lighter: near-bare-metal performance with roughly fifty to eighty percent less memory overhead than the same service in a full VM, so they are ideal for packing many small Linux services onto one host. Their limits are that they share the kernel, offer weaker isolation than a true VM, and run only Linux.

Full virtual machines run a complete guest operating system with hardware-level isolation, which is what you want for Windows workloads, for strong security separation between tenants, for a kernel different from the host, or for anything that needs its own operating-system environment. The practical pattern is to reach for containers first for internal Linux services, to save the memory, and use full VMs where isolation, a different operating system, or tenant separation makes them necessary — running both on one host to get the efficiency of containers and the isolation of VMs exactly where each is warranted rather than choosing one model for everything.

The hardware that virtualization needs

Virtualization rewards specific hardware choices, and getting them wrong is costly because they often mean replacing hardware rather than upgrading it. The CPU choice is density against per-core speed: AMD EPYC offers more cores per socket, more PCIe lanes, and higher memory bandwidth, which suits VM-dense hosts, while Intel Xeon leads on per-core performance for workloads that need it. ECC memory is assumed rather than optional at this scale, especially with ZFS, because a memory error in a host running dozens of VMs is a fault that can corrupt many workloads at once.

Storage and its controller matter as much as capacity. NVMe is the right backend for VM disk images — its high IOPS mean a write-heavy VM does not drag down its neighbors — and thin provisioning lets a pool of VMs with large nominal disks use only the space they actually consume. Critically, if you run ZFS or Ceph, the disks must be presented raw through a host bus adapter in IT mode, not hidden behind a hardware RAID controller, because ZFS and Ceph need direct disk access to checksum, self-heal, and manage their own replication — a hardware RAID card breaks exactly the guarantees they provide. And in a cluster, the heartbeat traffic that keeps nodes in sync needs its own network link, because sharing one NIC with storage and VM traffic lets congestion delay heartbeats and trick the cluster into thinking a healthy node has failed.

High availability and live migration

The features that make a virtualization host feel like a cloud are live migration and high availability, and on Proxmox they come without a licence tier. Live migration moves a running virtual machine from one host to another with no downtime — the equivalent of VMware’s vMotion — which is what lets you patch or maintain a physical host without interrupting the workloads on it. High availability goes further: when a host fails outright, the cluster automatically restarts its virtual machines on a surviving node, turning a hardware failure into a brief interruption rather than an outage.

Both depend on the virtual machines’ storage being reachable from more than one node, through shared storage, distributed storage like Ceph, or properly designed replication, and on a cluster of at least three nodes so that quorum survives losing one. Snapshots round out the picture, capturing a VM’s state instantly so you can roll back a change or take a consistent backup. These are the capabilities that justify clustering several dedicated servers rather than running one large host, and they are the reason a private cloud can offer availability that a single machine cannot — provided, as the earlier section stressed, it is sized to actually absorb the failure it is designed to survive.

A private cloud is critical infrastructure

It is worth being blunt about something the low cost of open-source virtualization can obscure: a private cloud is critical infrastructure, not cheap virtualization. Running Proxmox or any hypervisor in production demands the same discipline as any serious environment — well-designed networking, proper storage, quorum, high availability, backup, monitoring, failure testing, and steady day-to-day operations. The fact that the software is free does not make the operation free, and treating a production private cloud as a set-and-forget appliance is how outages happen.

The specific traps recur: overcommitting memory until the out-of-memory killer strikes, running a cluster too hot to survive a node loss, hiding disks behind a RAID controller that breaks ZFS, sharing one network link until congestion fakes a node failure. None of these is hard to avoid, but each has to be designed in from the start and monitored continuously, because workloads change — the VM that used little yesterday can become critical tomorrow, and the environment that started with ten VMs can grow to a hundred. A well-designed platform lets you add nodes, expand storage, and adjust resources without rebuilding, but that comes from designing it as production infrastructure rather than as an experiment that quietly went live.

Virtualization behind email infrastructure

Virtualization is not an abstract topic for us, because we run our own email infrastructure on it. A sending platform at scale is naturally a set of virtualized components — mail transfer agent nodes, the database, queue and tracking services, control interfaces — and virtualization is what lets those run with isolation between them, move between hosts for maintenance without interrupting sending, and fail over when hardware does. The same overcommit discipline applies: the database VM is never memory-overcommitted, the sending nodes get the CPU they need, and the cluster is sized to keep sending if a host is lost.

That direct experience shapes how we build virtualization hosts for others. We know the difference between a host that looks fine until a node fails and one designed to absorb the failure, because we operate that distinction on our own mail platform. When we spec a virtualization server or cluster, the storage, networking, and headroom decisions come from running production virtualization ourselves rather than from a datasheet, which is the same principle behind putting a heavy database on hardware sized to its real load.

Built and pre-configured from Toronto

We build virtualization hosts around the hypervisor and the fleet they will run: server-grade EPYC or Xeon CPUs with ECC memory, NVMe for VM images, a host bus adapter in IT mode when you run ZFS or Ceph, and the separate cluster networking a highly available setup needs. We can pre-install your chosen hypervisor — Proxmox, VMware, KVM, or Hyper-V — and hand over a host ready to build VMs on, with IPMI for full remote control. Our home data center is in Toronto, with servers in Frankfurt, Strasbourg, Amsterdam, Singapore, Panama City, and Miami, so a host or a cluster can sit where its data residency or latency needs it.

For a private cloud that should be run as well as built, our managed hosting covers the operations a production hypervisor demands — clustering, storage, backups, monitoring, and the failure testing that keeps high availability real. You can start from standard configurations in our configurator and we size the host or cluster to your VM density, your failover requirement, and your storage design from there, whether it is a single node or a clustered private cloud.

Why work with us?

We build virtualization hosts the way production actually requires: sized by memory rather than by CPU, because RAM is the constraint that bites; clustered with enough spare capacity to survive a node loss rather than run hot until one fails; and on the right storage controller, since an HBA in IT mode versus a hardware RAID card is the difference between ZFS working and ZFS silently broken. We will recommend the hypervisor that fits your team and commitments, usually Proxmox, rather than the one with the biggest brand.

The perspective comes from running our own email platform on virtualization, where a memory-overcommitted host or a cluster too hot to fail over is a problem we would feel in our own sending. We would rather build the host or cluster your workloads and your failover requirement actually need — and tell you when a managed private cloud would serve you better than running it yourself — than hand over hardware that works until the first node fails. A private cloud that survives the failure it was built to survive is the service.

Who this is for, and who it is not

A virtualization dedicated server is for teams running their own private cloud or VM fleet: organizations consolidating internal systems, VPS providers selling isolated instances, dev and test environments, and anyone who wants the control and total-cost advantages of running a hypervisor on owned hardware rather than renting cloud instances. If that is you, a host or cluster sized by the overcommit rules, built on ECC memory and the right storage controller, and designed to survive a node failure, is the foundation — and it will cost less over time than equivalent public cloud VMs for steady workloads.

It is not for a single application that a plain server or a managed platform would run more simply, nor for a team unwilling to operate real infrastructure and not opting for a managed private cloud, since virtualization in production is a standing commitment rather than a convenience. Read this page as a build guide with firm rules: if you are running a fleet and can operate it or have it managed, talk to us about a host or cluster designed to the density and failover you actually need; if your needs are simpler, we will point you to the plainer option. A private cloud built to survive failure, on hardware sized honestly, is what we are offering.