When the hypervisor stops earning its keep
This is the easiest page here to write honestly, because we sell both and have no reason to push you either way. Most workloads belong on a virtual machine. The ones that do not usually announce themselves, and their owners already know why.
What virtualisation costs
On modern silicon the compute overhead is small and boring. What you actually give up is access to the layer underneath, and for a handful of workloads that layer matters.
Less than people assume on CPU, more than they assume on control.
A few percent of CPU, and that is all
Hardware virtualisation has been mature for a decade. For ordinary application, database and web workloads the difference against bare metal sits in the low single digits, and it is smaller than the gap between two generations of chip.
An indirection on the I/O path
Storage and network traffic pass through a paravirtual driver. It is efficient, it is not free, and at very high packet rates it is the thing you will hit first.
No firmware, no board settings
Memory interleaving, power profiles, PCIe topology and boot behaviour are ours. If tuning any of that is part of your job, a virtual machine will frustrate you within a week.
Nested virtualisation is limited
Running your own hypervisor inside ours works for testing and poorly for production. Proxmox VE is available on metal and on the E-32 upward for exactly this reason.
You share a failure domain
Cores and memory are yours alone, but the node, its switch and its power feed are shared. A dedicated machine narrows that domain to one board you can point at.
What virtualisation buys
Everything below is a property of the abstraction rather than of the hardware, and each one disappears the moment you take the whole machine.
A new machine in 47 seconds
Median time from settled invoice to root credentials. Rebuilds, resizes and moves between sites are the same operation with a different destination.
Snapshots that take seconds
Point-in-time images on separate storage, five slots for €5 a month, restored in seconds. On metal, snapshots are a thing you build and then maintain.
Hardware failure becomes our problem
A dying NVMe or a failed PSU on a node means we move you, and you see a reboot. The same event on your own machine means a ticket, a wait, and a rebuild from backup.
A price floor of €29
Metal starts at €239 because it is a whole board with its own power and its own drives. Small workloads on metal are mostly paying for cores that idle.
Thirty-four cities without thirty-four commitments
Standing up an instance in a second jurisdiction takes a checkout, not a hardware order. Geographic spread is where virtual machines are hardest to beat.
Virtual against metal, as we price it
Both columns are our own catalogue, which makes this the one comparison on the site with no archetype in it at all.
| VPS | Bare metal | |
|---|---|---|
| Entry price | €29 a month | €239 a month |
| Time to provision | 47 seconds, median | Same day, usually within a few hours |
| Resize | Change plan, reboot | Order a different machine |
| Snapshots | Seconds, from the panel, €5 for five slots | Yours to build and operate |
| Hardware failure | We move you; you observe a reboot | We swap the part; you wait for it |
| Kernel and modules | Standard kernels, your modules within reason | Any kernel, any hypervisor, any partitioning |
| Firmware and board settings | Ours | Yours, over IPMI on a VPN |
| Noisy neighbours | None on dedicated cores | None, by definition |
| 32 cores and 256 GB | E-32 at €310 a month | BM-E at €529 a month, with 15.36 TB of NVMe |
| Cost per core once fully used | Higher | Lower |
The 32-core row is worth reading twice. The virtual machine is cheaper for the same core count; the metal costs €219 more and gives you the drives, the firmware and the board.
When metal is the better choice
You want to run your own hypervisor
Proxmox, or anything else that expects to own the machine. Nested virtualisation is a test environment, not a production platform, and pretending otherwise ends badly.
The storage layout is the product
ZFS across raw devices, specific stripe widths, or a cache tier you control. Talking to real drives is very different from talking to a block device we hand you.
Licensing is priced per socket or per core
Some software costs more on a virtual platform than the hardware would. Read the licence before choosing, because it occasionally decides the entire architecture.
You have a tight latency budget
Where jitter measured in microseconds is a requirement rather than a preference, remove every layer you can. That includes ours.
The machine will actually be full
At high, steady utilisation the cost per core on metal wins clearly. At thirty percent utilisation it is an expensive way to keep cores warm.
How to decide in five minutes
- 01
Measure current utilisation honestly
Take the ninety-fifth percentile of CPU and memory over a fortnight, not the peak that frightened you once. Below fifty percent on a machine you already own, metal is not the answer.
- 02
Ask whether you need the layer below
Firmware, hypervisor, raw devices, IPMI. A clear yes to any of them settles it immediately; a vague maybe means no.
- 03
Price the failure you can tolerate
One board is one failure domain. If a four-hour hardware replacement would be unacceptable, either buy two machines or take the virtual platform where moving you is routine.
- 04
Start virtual, then move
Run it on an E-32 for a month and measure. Migrating up to metal afterwards is a rebuild and a data copy, and it is far cheaper than discovering you bought a board you did not need.
“We were certain we needed metal. Two weeks of graphs said we needed one more virtual instance and a better index.”
Questions
Per core, close enough that the difference is hard to separate from run-to-run noise on most workloads, because the core is genuinely dedicated. Where you will see a gap is very high packet rates and direct device access.
On bare metal, yes, as a supported image. On the virtual side it is available from the E-32 upward, and below that we would rather you did not, since nested performance is not something we are willing to put an SLA against.
Yes, and people regularly do. It is a fresh build and a data copy rather than a live migration, so plan a maintenance window; support will hold both machines during the overlap.
Within what we already stock, usually within a day: drive counts, memory configurations, extra addresses. Anything requiring a purchase order for parts we do not hold is a conversation about lead times, not a quick yes.
Try it virtual before you buy the board
E-32 gives you 32 EPYC cores and 256 GB of ECC DDR5 for €310 a month. If the graphs then say you want the whole machine, BM-E is waiting and the migration is routine.