What is a VPS? How one physical server becomes many

When you order a VPS, nobody walks into a data centre and plugs in a machine for you. A server that is already running starts one more program, and that program becomes your server. You log in to a computer with its own operating system, its own disk and its own address on the internet, and you can do anything to it that you could do to a machine on your desk.

It is still a slice of someone else's hardware, though, and knowing where the slice ends explains most of what you will ever notice about a VPS: why it is cheap, why it can feel slower at eight in the evening than at four in the morning, and when it stops being the right tool.

One physical server, several private ones

A virtual private server is a virtual machine that a hosting company runs for you. The physical machine underneath is called the host; each virtual machine on it is a guest. The guests do not know about each other. Each one boots its own operating system, sees its own processors, memory, disk and network card, and gives you full control of all of it.

None of that hardware is real in the way the host's hardware is. It is presented to the guest by a program called a hypervisor, whose whole job is to share one set of physical parts between several operating systems without letting them step on each other. The word "private" in VPS refers to exactly that: the operating system, the files and the root password are yours alone, even though the metal is not.

The processor helps. Modern x86 chips carry virtualization extensions, which Intel calls VT and AMD calls AMD-V, and KVM, the hypervisor behind most Linux hosts, is built for x86 hardware that has them.¹ The extensions let the hardware itself keep guests apart, rather than leaving all of that to software.

The hypervisor: the program that does the slicing

Hypervisors come in two kinds. A type 1 hypervisor, also called native or bare metal, runs directly on the host's hardware and takes the place of a host operating system. A type 2 hypervisor runs as an application on top of an ordinary operating system, which is how desktop tools that run a second system in a window work.³ A VPS host wants as little as possible between the guests and the hardware, because every extra layer costs speed.

Most Linux-based hosts today use KVM, the Kernel-based Virtual Machine. KVM is not a separate product installed next to Linux. It is a pair of kernel modules: kvm.ko, which provides the core virtualization infrastructure, and a processor-specific module, kvm-intel.ko or kvm-amd.ko.¹Loading them turns the Linux kernel itself into the hypervisor, so everything Linux already knows how to do, from scheduling work onto cores to managing memory and talking to disks and network cards, is reused to run virtual machines. That reuse is a large part of KVM's appeal: it did not have to reinvent an operating system.

Red Hat describes the result in one line: every virtual machine is implemented as a regular Linux process, scheduled by the standard Linux scheduler, with its own virtual hardware.² Keep that sentence in mind, because the rest of this guide is mostly a consequence of it.

Where your vCPUs come from

A plan that says "4 vCPU" does not give you four pieces of silicon. It gives your virtual machine four virtual processors, and on the host each of them is a thread: KVM's own documentation talks about the thread that runs a vCPU, and notes that a vCPU thread can migrate between the host's logical processors.⁴ The host's scheduler decides, many times a second, which of those threads runs on which physical core.

Most of the time this is invisible. Web servers, databases and bots spend a large part of their lives waiting for a request, a disk or the network, and a vCPU that is waiting does not need a core at all. The host fills that gap with another guest's work. That is why a VPS can be sold cheaply: the provider is selling processor time on shared cores, and most customers need far less of it, most of the time, than the number of vCPUs on their plan suggests.

Steal time: the wait you can measure

The interesting moment in the drawing is the marked one. Guest B has work ready, but every core is running someone else, so B's vCPU waits. Inside B, Linux keeps count of exactly this. /proc/stat splits the time each processor spent into categories, and one of them is steal, defined in the kernel documentation as "involuntary wait".⁵ Tools such as top show it as st:

$ top -bn1 | head -3top - 14:02:11 up 12 days,  3:41,  1 user,  load average: 0.84, 0.77, 0.70Tasks: 142 total,   1 running, 141 sleeping,   0 stopped,   0 zombie%Cpu(s):  9.4 us,  2.1 sy,  0.0 ni, 87.9 id,  0.2 wa,  0.0 hi,  0.1 si,  0.3 st

Read the last number on the %Cpu(s) line. In this example 0.3% of the time a vCPU wanted a core and did not get one, which is nothing to worry about. If you see steal time climb into double figures whenever your server is busy, your work is queueing behind other guests. A faster application will not fix that. Cores that are allocated to you, rather than shared, will.

Memory: yours, as long as it is really there

Memory is handed to a guest differently. When your VPS boots, the hypervisor gives it a block of the host's memory that looks, from inside, like ordinary RAM. Unlike processor time, memory cannot be lent out and taken back a thousand times a second: a page of RAM holding your database cache is holding it, and nobody else can use that page at the same time.

That makes memory the resource where a host's honesty matters most. A host can promise its guests more memory in total than it physically has, betting that they will not all use it at once. Linux has tools that make this work better, such as Kernel Samepage Merging, a de-duplication feature that finds identical pages in different guests and keeps one copy; the kernel documentation notes that KSM was originally developed for use with KVM.⁶ Merging identical pages is harmless. Promising more memory than exists is not: when the guests do need what they were sold, the host has to push memory out to disk, and every guest on the machine slows down at once.

Disks and network cards that are really queues

A guest's disk is a file or a volume on the host's own storage, and its network card is a virtual device connected to the host's real one. The simplest way to present them is to imitate some well-known physical hardware. It works, but every read and write then has to be translated from an imitation device's registers into something the host can do, and that translation costs time.

KVM's answer is virtio, a set of paravirtualized drivers: the guest knows its devices are virtual and uses drivers written for that fact, and virtio was chosen as the main platform for I/O virtualization in KVM.⁷The heart of it is a shared queue. The virtio specification calls the mechanism for bulk data transport a virtqueue, and describes the driver making requests available to the device by adding them to the queue.⁸ The host takes them off the queue and turns them into real disk operations or packets.

Two things follow. First, the speed of your disk is mostly the speed of the host's disk, which is why the storage type on a plan matters: a virtual disk backed by NVMe inherits NVMe's low latency. Second, the host's disk and network card are shared. A guest copying a huge backup at full speed takes a share of the same throughput your database needs, which is the practical meaning of the phrase "noisy neighbour".

What is yours, and what you share

Put the pieces together and a VPS divides cleanly into what belongs to you and what you rent a share of. This table is the one to remember when you are deciding whether a VPS is enough.

A VPS is not a container

Containers, the thing Docker made popular, look similar from the outside, and some hosts sell them as small, cheap servers. They are built differently. Docker describes containers as isolated processes that share the operating system kernel with the other containers on the same machine, while each virtual machine includes a full copy of an operating system, the application and its libraries.⁹ A container is a fenced-off corner of one Linux system; a VPS is a separate system.

The difference matters the moment you need something from the kernel. On a VPS you can load a module, change a kernel setting, run a VPN that lives in the kernel, or run Docker itself. In a container you get whatever the host's kernel already allows. The trade goes the other way on weight: containers start in a moment and pack tightly, which is why they are a natural unit for deploying applications, often on top of a virtual machine.

When a VPS is the right choice

A VPS fits work that is bursty or mostly waiting: a website, an API, a small database, a VPN for a team, a bot, a staging copy of production, a game server with a modest crowd. For that kind of load, shared cores are not a compromise. They are the reason the price is low, and the moments when you do need a burst of processor are usually the moments when a neighbour does not.

The signs that you have outgrown it are specific. Steal time that climbs every time you are busy means you need cores that are not shared. Memory that you keep running out of means a bigger plan, not tuning. And if you need to run your own hypervisor, touch the hardware, or be sure that nobody else's work is on the same machine, you need the machine itself.

Clouduxe VPS sizes, on shared cores

1 to 12vCPU

Clouduxe VDS sizes, cores allocated to you

2 to 16cores

The AMD EPYC 4584PX under both

16cores