Virtualization on a dedicated server: KVM, Proxmox or ESXi

On your own hardware there are three options: plain KVM with libvirt, Proxmox VE (the same KVM plus LXC containers and a web panel) or VMware ESXi. Most projects take Proxmox VE: it installs on top of Debian, runs both virtual machines and containers, and needs no purchased licence. ESXi makes sense where VMware infrastructure and the staff for it already exist.

Hardware virtualization must be enabled in the BIOS: on Intel that is VT-x, the vmx flag in /proc/cpuinfo.
Do not overcommit memory: the sum of RAM across all guests plus 2-4 GB for the hypervisor has to fit into physical RAM.
Cores can be overcommitted safely: 3-4 vCPU per physical thread is normal for uneven load.
Every guest with its own public address needs a separate IPv4: $5/month.
Without KVM/IPMI, one mistake in the bridge configuration cuts off access to the server; the option costs $5/month.

What the hardware has to provide

A hypervisor runs out of memory and disk long before it runs out of CPU. Guest memory is allocated in full and does not shrink, so 16 GB on a Start plan is really 12-13 GB for guests once the hypervisor and the cache are subtracted. Disks need IOPS headroom: ten guests write randomly and simultaneously, so NVMe in RAID1 beats a pair of SATA SSDs by multiples, not percentages.

ECC memory is not a luxury here: a single flipped cell in host memory corrupts a page inside any guest, and diagnosing that afterwards is extremely hard. Every ZevsHost dedicated server ships with DDR4 ECC; the configurations are listed on the dedicated servers page.

The third requirement is out-of-band management: installing a hypervisor and recovering from a failed kernel upgrade happen through a console, not over SSH. How that works is described in the article on IPMI and KVM-over-IP.

Checking virtualization support

The first thing to do on a new machine is confirm that KVM is available. If the flags are missing, virtualization is disabled in the BIOS and you cannot turn it on over SSH.

# vmx (Intel) or svm (AMD) flag in the CPU description
grep -c -E 'vmx|svm' /proc/cpuinfo

# kernel module loaded and the device node created
lsmod | grep kvm
ls -l /dev/kvm

# Debian/Ubuntu: full host readiness check
apt-get install -y libvirt-clients qemu-kvm
virt-host-validate qemu 2>&1 | grep -v PASS

# RHEL/AlmaLinux/Rocky
dnf install -y libvirt-client qemu-kvm
virt-host-validate qemu

Output from virt-host-validate with no WARN and no FAIL lines means the host is ready.

Choosing a hypervisor

Option	Management	When to take it	What it costs you
KVM + libvirt	virsh, virt-install, XML files	2-5 guests, everything automated with scripts or Ansible	No panel; snapshots and backups are on you
Proxmox VE	Web panel, API, CLI (qm, pct)	Mixed load, machines and containers, backups and clustering	Needs a separate storage partition, its own network stack
VMware ESXi	Host Client, vCenter	VMware infrastructure and specialists already in place	Strict driver requirements, licensing
LXC containers	pct in Proxmox or lxc	Uniform Linux environments, density over isolation	Shared kernel with the host, no foreign kernel inside

Once you pass three guests, a panel pays for itself in the first week. What Proxmox is and how it differs from bare KVM is covered in Proxmox explained, the step-by-step setup is in installing Proxmox, and the storage decision is in the article on ZFS storage in Proxmox.

Networking: bridge and addresses

There are two schemes. A bridge puts guests into the same network as the host, one public IPv4 per guest. NAT keeps guests in a private subnet and forwards ports from the single host address.

# Debian/Proxmox: a bridge on top of the physical interface
cat << 'EOF' > /etc/network/interfaces.d/vmbr0
auto vmbr0
iface vmbr0 inet static
    address 203.0.113.10/24
    gateway 203.0.113.1
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0
EOF

# apply and immediately verify the bridge came up
ifreload -a
ip -br addr show vmbr0
bridge link show

Addresses and subnets for guests are ordered separately at $5/month per IPv4; how to route them is covered in the article on extra IPv4 addresses and subnets.

How many guests fit on a plan

Plan	RAM	Disks	Realistic density
Dedicated Start DE, $49	16 GB ECC	2x500 GB SSD, RAID1	3-4 guests at 2-4 GB
Dedicated Pro DE, $99	32 GB ECC	2x1 TB NVMe, RAID1	6-8 guests at 4 GB
Dedicated Enterprise US, $149	64 GB ECC	4x1 TB NVMe, RAID10	12-16 guests at 4 GB

These numbers already leave room for the hypervisor and the cache. For snapshots, budget another 20-30% of disk: a snapshot grows by the volume of changed blocks.

Overcommitting memory on a hypervisor without swap ends with the OOM killer taking down not the guilty guest but the largest one, which is usually the production database. Run free -m on the host with all guests under load and keep available at no less than 10% of physical RAM. The second way to lose a server is reconfiguring the bridge over SSH: the connection drops on the apply command, and without KVM/IPMI you cannot bring the machine back. Change networking only from the IPMI console.

Key takeaways

Proxmox VE covers most scenarios: KVM, LXC, a panel and backups; plain libvirt is justified at 2-5 guests.
Before installing, check the vmx flag and the virt-host-validate output: without hardware support the hypervisor will not start.
Do not overcommit memory, do overcommit cores: 3-4 vCPU per thread under uneven load.
Every guest with a public address needs its own IPv4 at $5/month, or NAT with port forwarding.
Reconfigure networking only from the IPMI console: a mistake in the bridge cuts SSH instantly.

Virtualization on a Server: KVM, Proxmox or ESXi