VDS vs VPS: is there a difference?

What the two words mean

VDS vs VPS is a naming difference before it is a technical one. VDS is short for virtual dedicated server. VPS is short for virtual private server. Both describe one slice of a physical machine, sold to you as if it were a machine of your own. A minority of hosts give the words separate meanings: VDS for a full virtual machine with reserved CPU and RAM, VPS for a container that shares the host's kernel. Most hosts use both words for the same product. So the word on the price page tells you little. Four commands on the server, and a few questions to the host, tell you what you bought.

Where "virtual dedicated server" came from

Both terms date from the early 2000s, when hosts began slicing one physical server into many. The first common tools were containers: FreeBSD jails, and on Linux the Virtuozzo product from SWsoft, released as open source under the name OpenVZ in 2005. A container is a group of processes with its own filesystem and network, running on the host's kernel. Full virtual machines reached cheap hosting later, with Xen (first released in 2003) and then KVM, which joined the Linux kernel in 2007.

The marketing problem was the same for every host. A dedicated server was the product customers understood, and a slice of one needed a name that sounded like a dedicated server without being one. "Virtual private server" stressed isolation: your own processes, your own root login, your own IP address, your own files. "Virtual dedicated server" stressed the resource guarantee: a CPU share and a block of RAM sold as if they were a whole box. GoDaddy sold its line as "Virtual Dedicated Servers" for years before renaming it to VPS. No standards body defines either term, and no host is obliged to use one rather than the other.

VDS vs VPS: the split some markets still use

In Russian-speaking hosting, and in parts of the Turkish and Central European markets, a convention grew up in the container era and never fully went away. VPS meant the cheap product: an OpenVZ or later LXC container, sharing the host's kernel, with CPU and RAM limits the host could oversell. VDS meant the expensive product: a full virtual machine under KVM or Xen, with its own kernel, and CPU cores and RAM the host claimed to reserve for you. The container product costs less because the host can pack more containers onto one machine, and an idle container gives its CPU back. The VM product costs more because the host sets memory aside for it whether you use it or not.

Read as a convention, this is useful. Read as a rule, it fails. Plenty of hosts in those same markets sell KVM plans as VPS. Others sell containers as VDS. Some sell KVM plans with shared CPU as VPS and KVM plans with pinned cores as VDS, so both words mean a VM and the difference is only the CPU policy. The convention tells you what one host probably means. It never tells you what a specific host actually means.

Why most hosts now use the words interchangeably

KVM became free and easy to automate, so the cost gap between a container and a VM shrank. Customers learned that "container" often meant a crowded machine, so hosts stopped advertising that part. Search traffic rewarded whichever word people typed most, which in English is VPS. And hosts merged their product lines, so one KVM plan replaced the old pair. Today most English-language hosts sell KVM machines and call them VPS, and some keep VDS as a second name for the same thing so that searches for either word land on the same page. The word tells you about the host's marketing history. What the machine is, and what it can run, are answered by the checks below.

Find out what you bought: four checks

Run these on the server itself. None of them changes anything. Each one can give several answers, and the answers are explained after the command. If you try them first inside a Docker or LXC container on your own computer, you get the container answers, which is a fair preview of the cheaper product.

Check 1: which virtualisation is underneath

systemd-detect-virt
systemd-detect-virt --vm
systemd-detect-virt --container

The first command prints one word. kvm, qemu, xen, vmware, microsoft or oracle mean a full virtual machine: the box has its own kernel and its own memory. openvz, lxc, lxc-libvirt, docker or systemd-nspawn mean a container: you are a group of processes on the host's kernel. none means bare metal, or a hypervisor that hides itself.

The other two commands split the question. A container running inside a virtual machine reports the container on the first command, so --vm is how you ask what sits underneath. If --container prints none and --vm prints kvm, you have a plain KVM machine. If --container prints openvz or lxc, you bought a container, whichever word the price page used. The command exits with status 0 when it finds any virtualisation and 1 when it finds none, so it works in scripts too.

Check 2: the hypervisor line in lscpu and /proc/cpuinfo

lscpu | grep -iE 'hypervisor|virtualization|model name|^CPU\(s\)'
grep -m1 -o hypervisor /proc/cpuinfo || echo "no hypervisor flag"

A virtual machine shows a Hypervisor vendor: line, usually KVM, Xen, VMware or Microsoft, and a Virtualization type: full line with it. The hypervisor flag in /proc/cpuinfo is set by the CPU itself when it runs under a hypervisor, so the second command reads the same signal a second way.

A container gives a confusing answer here, and the confusion is the useful part. In many containers /proc/cpuinfo is the host's file, so CPU(s) is the host's core count and the hypervisor line describes the host, not you. A "4 vCPU" plan whose lscpu reports 64 CPUs is a container with a CPU limit set in cgroups, and that limit is invisible from this file. Some hosts install lxcfs, which rewrites /proc/cpuinfo and /proc/meminfo to show your limits, so a sensible-looking count does not prove a VM on its own. Model name is worth reading in both cases: it names the host's CPU generation, which is the one hardware fact the host cannot hide.

Check 3: steal time

timeout 20 sha256sum /dev/zero > /dev/null &
vmstat 1 15

The first command loads one CPU fully for twenty seconds. The second prints one row per second. Ignore the first row, which is an average since boot, and read the st column. That is steal time: the percentage of time your virtual CPU was ready to run but the host gave the physical core to someone else. A value that stays near zero while you load the CPU means the core was yours when you asked for it. A value that sits at ten or twenty percent means the host has sold that core to more customers than it can serve at once. That is what "dedicated" in VDS is supposed to rule out, and this column is the only place a guest can see it: no file inside the guest records whether the host reserved your cores or shared them, and nproc counts the vCPUs you were given, not the cores behind them.

Two cautions. Fifteen seconds is a sample, not a verdict, because a quiet Sunday says nothing about Monday morning. And in a plain LXC or Docker container, /proc/stat is usually the host's file, so the column describes the whole machine and not your share of it. The long-form version of this test, with sysbench and a week of samples, is in how to measure CPU steal time and prove a noisy neighbour.

Check 4: whether the kernel is yours

uname -r
ls /boot
dpkg -l 'linux-image-*' 2>/dev/null | grep '^ii' || echo "no kernel package installed"
sudo modprobe wireguard && echo "module loaded"

On a virtual machine, uname -r names a kernel, dpkg lists that kernel as an installed package, /boot holds the vmlinuz and initrd.img files it booted from, and modprobe loads the module, because the kernel is yours to change. You can install a different kernel, or replace Ubuntu with FreeBSD from a rescue ISO.

In a container, uname -r names the host's kernel, /boot is empty or missing, no linux-image package is installed, and modprobe fails with Module wireguard not found in directory /lib/modules/... or with Operation not permitted. Both errors mean the same thing: the kernel belongs to the host, and a module the host has not loaded for you does not exist. A kernel name containing stab or vz is an OpenVZ host kernel, and on OpenVZ the file /proc/user_beancounters also exists, holding the container's real resource limits. free -m in a container without a virtualised /proc/meminfo reports the host's whole memory, and your real limit only shows itself when a process is killed for exceeding it.

This is the difference that decides what you can run. WireGuard, Docker with its own storage drivers, nested virtual machines, and any software that needs a kernel module all depend on this answer. The wider list of software that only works on one side of this line is in will it run on a VPS, and the hypervisor families themselves are compared in KVM vs Xen vs LXC for a VPS.

The checklist: what to ask before you pay

Both words will stay on price pages for as long as people search for both. Ignore the word and get answers to these questions, in writing, from the host's documentation or support.

1. Which technology: KVM, Xen, VMware, Hyper-V, or a container such as OpenVZ or LXC?
2. Are vCPUs reserved or shared? If shared, what is the overcommit ratio, and what does the fair-use policy do to a customer who runs at 100 percent all day?
3. Is RAM reserved for the machine, or oversold with ballooning? Is swap real disk?
4. Can I boot my own kernel, or mount my own ISO to install an operating system the host does not offer?
5. Is the disk local NVMe, or a network block device? Are IOPS limited?
6. Is nested virtualisation enabled, if you plan to run virtual machines of your own?
7. What does the word on your price page mean at this host, and where is that written down?

A host that answers all seven clearly is selling a product it understands. A host that answers "it's a VDS" to the first question has not answered it. When the answers describe a full virtual machine with reserved resources, you have what the strict VDS definition promises, whichever word is printed. When they describe a container with shared limits, you have a VPS in the strict sense, which is fine for many jobs if the price reflects it. What either product hands over, from the root login to the limits behind it, is set out in what a VPS actually gives you. If these questions lead you to want the hardware to yourself, the trade-offs on that side are in VPS vs dedicated server, and the wider vocabulary of virtual machines and private clouds is in VPS vs VM vs VPC.

FAQ

Is a VDS better than a VPS?

Not by definition. At hosts that split the terms, VDS is the full virtual machine with reserved CPU and RAM, and VPS is the container, so VDS is the higher tier. At most hosts the two words name the same product. Judge a plan by the technology, the CPU policy, the kernel access and the price, not by the initials.

How do I check if my VPS is KVM or OpenVZ?

Run systemd-detect-virt. It prints kvm for a KVM machine and openvz for an OpenVZ container. As a second check, ls /boot shows kernel files on a KVM machine and nothing in a container, because a container runs on the host's kernel. On OpenVZ the file /proc/user_beancounters exists and holds your real limits.

What does steal time tell me about my VPS?

It is the percentage of time your vCPU was ready to run but the host gave the physical core to another customer. Read it in the st column of vmstat 1 while you load a CPU. Values near zero under load mean the core was available to you. Values that sit at ten percent or more mean the host has oversold the core, which is what a reserved-CPU plan is supposed to prevent.

Can I install my own kernel on a VPS?

Only on a full virtual machine. A KVM or Xen guest boots its own kernel from its own /boot, so you can install a different kernel or a different operating system. A container shares the host's kernel, so uname -r shows a kernel you did not install, and modprobe cannot load modules the host has not provided.

Does the word VDS mean the CPU cores are dedicated?

Not on its own. Some hosts use VDS for plans with reserved cores. Others use it for any KVM machine, shared cores included. Ask the host whether vCPUs are reserved and what the overcommit ratio is, then confirm the answer with steal time measured over several days.