Bare metal vs virtual machine: performance, isolation and licensing compared

The bare metal vs virtual machine question comes down to one layer of software: the hypervisor. A virtual machine (a cloud instance or VPS) is a slice of a physical host carved out by a hypervisor; every CPU cycle, memory access, disk read and network packet passes through that virtualization layer. A bare metal server is an entire physical machine handed to a single tenant, with the operating system running directly on the hardware, yet ordered from a console, provisioned automatically and billed by the hour or month like a cloud instance. Whether that hypervisor exists decides everything in the six dimensions below. The table gives the overview; the sections that follow explain each row.

Dimension	Bare metal server	Virtual machine
Performance overhead	No virtualization layer; I/O latency and memory access are those of the hardware itself	Small loss on compute-bound work; noticeable loss on disk I/O, network I/O and memory-intensive workloads
Resource contention	Single tenant; the whole machine is yours	Multi-tenant host; CPU, cache, memory bandwidth and disk queues can all be affected by neighbors
Licensing	Licensed by real physical cores, and you choose the core count	Licensed per vCPU, or under some policies by every physical core of the host or even the cluster
Nested virtualization	Install KVM, ESXi or Hyper-V directly and run your own virtualization platform	Needs the provider to expose nested virtualization; heavy performance penalty
Elasticity	Provisioning takes minutes to hours; fixed configuration; no live migration	Created in seconds to minutes; resize, snapshot, live-migrate, autoscale
Price	Cheaper per unit of compute, but you buy a whole machine	Tiny sizes available; more expensive per unit of compute

Performance overhead: CPU loses little, I/O and memory lose more

With hardware-assisted virtualization (Intel VT-x, AMD-V), pure compute workloads typically lose only a few percent inside a virtual machine, so compile jobs or video transcoding perform about the same on both. The gap shows up in three places:

• Disk and network I/O. Every I/O operation in a VM goes through a paravirtualized driver such as virtio, or an emulated device, and is then forwarded by the host; network-attached block storage adds another hop across the network. The result is higher latency per operation and a lower ceiling on small random IOPS. SR-IOV passthrough NICs reduce the network part, but not every instance type offers them.
• Memory access. A VM uses two-level page tables (Intel EPT, AMD NPT) to map guest physical addresses once more, so a TLB miss costs more than on a physical machine. The NUMA topology the guest sees may also differ from the real hardware, which breaks database optimizations that pin memory to NUMA nodes. On bare metal you can enable huge pages, pin NUMA and turn off hyper-threading, and databases, in-memory stores and search engines show the benefit directly.
• Latency jitter. Host scheduling and interrupt forwarding add microseconds of unpredictable delay to a VM. A web application never notices; order matching, real-time audio and video, and time-series databases with heavy write rates see it in tail latency (P99).

A simple test: if your bottleneck is CPU throughput, a VM is fine. If the bottleneck is random disk I/O, memory bandwidth or tail latency, bare metal pays off.

Noisy neighbors: only bare metal removes them entirely

A vCPU generally maps to one hardware thread of the host, not to a physical core. The provider sells the vCPUs of one host to several tenants, and as long as the total does not exceed the number of hardware threads it is not counted as oversubscription. Even without oversubscription, though, the two threads of one physical core, the L3 cache and memory bandwidth of one CPU, and the I/O queue of one local disk are shared. When a neighbor saturates memory bandwidth, your vCPU utilization looks low, your application slows down, and nothing in your monitoring explains why.

cgroups and the hypervisor can cap CPU time, memory capacity and disk bandwidth. L3 cache and memory bandwidth can be partitioned with Intel RDT and similar technologies, but public clouds generally do not carve them out per tenant. Bare metal is single tenant: all of these resources are yours, and performance is reproducible. The numbers from today’s load test will not change next month because a different neighbor moved in.

Isolation also affects security mitigations. Mitigations for CPU side-channel vulnerabilities such as Spectre, Meltdown and MDS are normally fully enabled on multi-tenant hosts, and they cost real performance on syscall-heavy workloads. On single-tenant bare metal you decide how far to enable them based on your own risk assessment.

Licensing: why per-core software favors bare metal

A lot of commercial software is licensed by physical core rather than by vCPU, and on a shared virtualization platform the math turns ugly. The summary below follows the vendors’ published rules; their current license terms take precedence:

• Oracle Database is licensed per Processor, where Processors = physical cores × core factor (0.5 for mainstream x86). Oracle’s partitioning policy classifies VMware and most other hypervisors as soft partitioning, does not accept vCPU counts, and requires licensing every core of every physical host the VM could run on. Oracle recognizes some public clouds as Authorized Cloud Environments where vCPUs are counted instead; the list and the conversion rules are whatever Oracle’s current policy says.
• Microsoft SQL Server (per-core model): a physical server must license all physical cores with a minimum of 4 per processor; a VM licenses its vCPUs with a minimum of 4 per VM. To run any number of SQL Server VMs on one host, you license all physical cores with Enterprise edition plus Software Assurance.
• Windows Server is licensed per physical core with a minimum of 16 cores per server. Standard edition covers 2 virtual machines; Datacenter edition covers an unlimited number.

A hypothetical example: a database needs 8 physical cores.

Deployment	Cores to license	Why
Shared virtualization cluster, 3 hosts with dual 16-core CPUs	96	Under soft-partitioning rules, every host the VM could migrate to counts
One bare metal server with dual 16-core CPUs	32	Only this machine is licensed, but you pay for 24 cores you do not need
One bare metal server with a single 8-core, high-frequency CPU	8	Exactly the cores you need, high clock speed, smallest license bill

So when per-core software drives the choice, the goal is not many cores but just enough cores at the highest clock speed you can get, with the license savings spent on faster NVMe and more memory. On bare metal, lscpu and dmidecode show the real CPU model and core count, which is the evidence you need in a license audit.

Nested virtualization: your own hypervisor needs bare metal

Install KVM, Proxmox VE, VMware ESXi or Hyper-V on a bare metal server and you have your own virtualization host with the same performance as a physical machine in your own data center. Typical uses: a private cloud, one VM per customer or per environment, container sandboxes built on lightweight VMs such as Kata Containers or Firecracker, Android emulators in CI, virtual desktops.

Running a VM inside a VM is nested virtualization. It requires the provider to expose the VT-x or AMD-V instructions to the guest, which many instance types do not do by default; even when they do, two layers of address translation stack up and the inner VMs are noticeably slower, which limits the setup to development and testing. Once logged in, you can check:

# A non-zero result means the CPU virtualization extensions are visible and KVM can be installed
grep -cE 'vmx|svm' /proc/cpuinfo

# On bare metal, if the VMs you create should themselves run VMs,
# check the nested flag of the KVM module (kvm_intel for Intel, kvm_amd for AMD); Y or 1 means enabled
cat /sys/module/kvm_intel/parameters/nested 2>/dev/null
cat /sys/module/kvm_amd/parameters/nested 2>/dev/null

If the first command prints 0 inside a VM, that VM cannot run KVM; the fix is a different instance type or a bare metal server.

Elasticity: VMs in seconds, bare metal in minutes to hours

The VM’s strength: it is created in seconds to minutes, can be resized online, given more disks, snapshotted and live-migrated to another host, scaled up and down automatically with load, and stops costing compute money when it is powered off.

Bare metal is a step behind. Provisioning means powering on a real machine and installing an OS, which takes minutes to hours. The configuration is fixed by the physical hardware, so more memory means a different machine. There is no live migration: a hardware failure is your outage, and your own high-availability design has to absorb it. Bare metal with local disks usually has no snapshots, so backups are on you. Cloud providers that put the bare metal system disk on block storage and attach the server to a VPC can recover from a hardware failure by attaching that disk to another server, which is a big improvement over traditional dedicated servers, but still not the clone-a-hundred-copies elasticity of VMs.

If your load swings during the day, the machine count follows traffic, or you constantly build and tear down environments, choose VMs. If the load is steady, the machines run all the time and the fleet size is fixed, elasticity is worth nothing to you and bare metal costs less.

Price: cheaper per core on bare metal, cheaper entry with VMs

For the same CPU generation, bare metal costs less per physical core than VMs, because when a machine is sold in small slices, every slice carries a share of the virtualization platform, scheduling and operations, and small sizes are priced higher per unit anyway. But bare metal is sold as a whole machine, and the smallest option is often dozens of cores and over 100 GB of memory, while a VM can be 1 vCPU with 1 GB.

A set of hypothetical numbers (for illustration only; real prices vary by provider and region): a 32-core, 128 GB bare metal server at $800 per month, which is $25 per core; an 8 vCPU, 32 GB VM at $320 per month, which is $40 per vCPU.

Requirement	VM option	Bare metal option	Cheaper
Small application, 8 cores and 32 GB	1 VM, $320	1 server, $800, with 24 cores idle	VM
Database, 24 cores and 96 GB	3 VMs, $960, split across machines	1 server, $800, with 8 cores to spare	Bare metal
Workload that fills 32 cores	4 VMs, $1,280	1 server, $800	Bare metal

The rule of thumb: if you can keep a bare metal server 60 to 70 percent busy or more, it is cheaper than the equivalent VMs; if you only need a fraction of it, VMs are cheaper. Add the licensing differences above, and database and middleware workloads, which are licensed per core and heavy on I/O, are usually where bare metal pays for itself first.

How to choose, and how to verify you got a physical server

By workload

Workload	Recommendation	Reason
Oracle, SQL Server and other per-core licensed databases	Bare metal	Licensing by real physical cores, low I/O latency
Large MySQL or PostgreSQL instances, Redis, Elasticsearch	Bare metal	Local NVMe, huge pages and NUMA pinning pay off
Order matching, real-time bidding, media relay and other tail-latency-sensitive work	Bare metal	No scheduling jitter, no neighbors
Your own virtualization, container sandboxes, cloud gaming, emulator farms	Bare metal	Needs full virtualization extensions
GPU training and inference	Bare metal	Whole GPUs, direct PCIe
Compliance requires physical isolation	Bare metal	Single tenant, hardware details available on request
Web front ends, APIs, microservices	VM	Stateless, horizontal scaling, elasticity has value
Development, testing, CI runners, temporary environments	VM	Create and delete at will
Workloads with large load swings	VM	Autoscaling, pay for what you use
Small applications that need one or two cores	VM	A whole bare metal server would sit idle

Acceptance: confirm it is a physical machine

If you paid for bare metal, you should receive a physical machine. After logging in, check with a few commands:

# A physical machine prints none; a VM prints kvm, vmware, microsoft and so on
systemd-detect-virt

# VMs have the hypervisor flag in /proc/cpuinfo, physical machines do not; expect 0
grep -c hypervisor /proc/cpuinfo

# A physical machine shows the board or system vendor (Dell Inc., Supermicro, ...); a VM shows QEMU, VMware, Inc. and the like
cat /sys/class/dmi/id/sys_vendor
cat /sys/class/dmi/id/product_name

# Compare CPU model, socket count, physical cores and threads with your order
lscpu | grep -E 'Model name|Socket|Core|Thread'

Then check two more things. First, out-of-band management: a real physical server should give you power control, boot device selection, ISO mounting and a console that shows the BIOS screen, even if the provider’s panel sits in between (the IPMI remote management guide explains where these capabilities come from). Second, the disks: nvme list or lsblk -d -o NAME,MODEL,SIZE should show real drive models from manufacturers such as Samsung, Intel, Micron or Kioxia, while a VM typically shows names like QEMU HARDDISK or Virtual Disk, and the model column of a virtio disk is often empty. When both checks pass, the machine is a physical server that belongs to you alone.