Most hosting today runs on virtual machines or containers. A hypervisor divides one physical server into many virtual ones, each with its own operating system and a guaranteed share of CPU and memory. Containers go lighter, sharing the host's kernel while isolating applications from each other.
This is what lets providers resell capacity in small pieces, move a virtual server to a healthier machine while it runs, and bring new capacity online in minutes. The trade-off is overhead and the possibility of neighbours competing for shared resources, particularly disk and network.
Two ways to slice a server
A virtual machine pretends to be a whole computer. The hypervisor, which on Linux hosts is commonly KVM, presents virtual CPUs, memory, disks and network cards, and each guest boots its own kernel. Because the guest believes it has real hardware, you can run a different operating system from the host, and a crash in one guest does not touch another.
A container is a normal process with blinkers on. The kernel uses namespaces to limit what the process can see (its own file system, process list and network) and control groups to limit how much CPU, memory and I/O it can use. There is no second kernel to boot, so containers start in a fraction of a second and waste little memory. The cost is weaker isolation: every container shares one kernel, so a kernel flaw is everyone's problem.
Moving a server while it runs
Because a virtual server is just memory and a disk image under software control, a provider can relocate it. In live migration, the hypervisor copies the guest's memory to another host while it keeps running, re-copies pages that changed in the meantime, and finally pauses the guest for a few milliseconds to hand over the last of the state. Network traffic then follows it to the new location. For the customer, this looks like nothing, or one slightly slow second.
It is how hosts empty a machine before maintenance or retire one that is showing disk warnings. It works best when the disks sit on shared storage, so only memory needs to travel.
Neighbours and noisy ones
Sharing is the whole economic point, and it has a downside. If the hypervisor gives out more virtual CPUs than there are real cores, which is called overcommitting, then a busy neighbour can leave your VM waiting for its turn. Disk and network are harder to partition than memory, so a neighbour running a heavy backup can raise your I/O latency without taking any of your allocation.
Providers manage this in different ways. Some pin virtual CPUs to dedicated cores, which costs more but removes the queue. Others limit each guest's disk operations per second so no single tenant can flood the array. Memory is usually the most strictly allocated resource, since running out of it is immediately visible, but some hosts use ballooning, which reclaims unused guest memory when the host is under pressure. Ask which model your plan uses before you rely on a number in a product page.
What changes by hosting type
| Type | Isolation | Resources | Contention risk |
|---|---|---|---|
| Shared hosting | Accounts on one server, often containerised or jailed | Capped per account | Moderate |
| VPS | Own kernel under a hypervisor | Guaranteed share | Low to moderate |
| Dedicated | Whole machine | All of it | None from neighbours |
Verifying it
On a Linux VPS you can see virtualisation at work. systemd-detect-virt names the technology, lscpu shows the hypervisor vendor, and top has a column that matters: st, steal time, the share of time the VM was ready to run but the host gave the CPU to someone else.
$ top -bn1 | head -3 | tail -1
%Cpu(s): 9.2 us, 2.1 sy, 0.0 ni, 78.4 id, 0.3 wa, 0.0 hi, 0.2 si, 9.8 st
$ iostat -x 5 3Steal that stays above a few percent while the machine is otherwise idle is worth raising with the provider. High wa or a large await in iostat points at disk contention. The troubleshooting guide helps when you are unsure where slowness begins.
Smaller questions
Is a container the same as a VPS?
No. A VPS has its own kernel; a container shares the host's. Containers are lighter, VPS isolation is stronger.
Can my provider see inside my VM?
The hypervisor can in principle read a guest's memory and disk. Trust, contracts and disk encryption govern that, not technology alone.
Does virtualisation slow my site?
The direct overhead is small on modern hardware. Contention from neighbours is the bigger risk.