What Is a Virtual Dedicated Server? VDS vs VPS vs Dedicated

What a virtual dedicated server actually is

A virtual dedicated server (VDS) is a virtual machine carved out of a physical host by a hypervisor (most often KVM on Linux, sometimes Xen, VMware ESXi or Hyper-V), with one defining property: the resources on the invoice are reserved. Two cores means two host threads set aside for that VM; 8 GB of RAM means 8 GB the host never lends to another tenant. Inside the machine you get your own kernel, your own disk image, full root or Administrator rights, and any operating system the hypervisor can boot: a small dedicated server from the guest's point of view, one tenant among several that never compete for the same allocation from the host's.

The term exists because "VPS" became too broad. A VPS can be anything from an OpenVZ container with burstable RAM to a KVM machine on a host that sells the same physical core to six customers. "VDS" was adopted by providers who wanted to say "this one is not oversold". There is no standard behind the label: in the Russian-speaking hosting market VDS and VPS are interchangeable, and some providers elsewhere relabel a plain VPS line because VDS sounds closer to dedicated. The word tells you the intent; the commands below tell you the truth.

VDS vs VPS vs dedicated server

The products differ on two axes: how the machine is isolated (container, virtual machine, or physical hardware) and whether resources are reserved or shared. A VDS sits between a shared VPS and a dedicated server on both.

The price column is a rough 2026 range for entry-level plans, not a benchmark. A four-core, 8 GB reserved VM cannot be sold for $3 a month; when a "VDS" is priced like a container, it usually is one.

Reserved vs shared resources: where the difference lives

CPU. On KVM, each vCPU is a host thread the Linux scheduler treats like any other process. A host with 32 hardware threads can be sold as 32 vCPUs (1:1, reserved) or as 128 vCPUs (4:1, shared). Nothing inside the guest displays that ratio; it only becomes visible as steal time and latency spikes when the neighbours are busy.

RAM. KVM hosts overcommit memory in two ways: the virtio balloon driver lets the host reclaim pages a guest is not using, and KSM (kernel samepage merging) deduplicates identical pages across VMs. On a reserved plan the memory is committed when the VM starts and the balloon is never inflated. Seeing virtio_balloon in lsmod proves capability, not use: the driver ships in nearly every cloud image.

Storage. Reservation rarely extends to disk; almost every provider shares the storage backend and caps IOPS per VM at most. What changes performance is the tier underneath: an NVMe drive delivers far more IOPS and lower latency than a SATA SSD, and no CPU reservation compensates for a slow disk under a database.

Network. The uplink is shared on everything short of a dedicated server with its own port; "unlimited" bandwidth means unlimited under a fair-use policy, not a guaranteed 1 Gbps to you alone.

KVM vs container virtualisation (OpenVZ, LXC)

This split decides whether a "VDS" can be dedicated at all. KVM, Xen and ESXi are hardware virtualisation: VT-x or AMD-V lets each guest run its own kernel on virtual hardware. OpenVZ, Virtuozzo, LXC and Docker are operating-system-level virtualisation: every tenant is a set of processes on the host's kernel, separated by namespaces and limited by cgroups. Proxmox calls these "CT", and many low-cost hosts sell them as VPS. The consequences:

• uname -r returns the host's kernel, which you did not choose and cannot upgrade. Historically OpenVZ hosts ran very old kernel series. If you are unsure what a box really runs, the commands to find the OS and kernel version on Linux, Windows and macOS take seconds.
• You cannot load kernel modules: WireGuard, ZFS and anything shipped as a .ko depend on the host.
• Nested virtualisation is impossible, and Docker or systemd inside the container works only if the host allows it.

A KVM guest has none of those constraints: it boots from an ISO, runs any kernel, and can expose VT-x to its own guests if the host allows nested virtualisation. A genuine VDS is therefore always a full VM.

Noisy neighbours and steal time

A noisy neighbour is another tenant on the same host whose CPU, disk or network usage cuts into yours. On an overcommitted KVM host the scheduler queues your vCPU behind theirs, and the time your vCPU spent runnable but waiting is reported back to the guest as steal time. Linux exposes it as the eighth value on the cpu line of /proc/stat, as the st column of vmstat and top, and as %steal in mpstat and sar.

A reserved VM should show steal at or near zero even while its neighbours run flat out. A few percent during bursts is normal on shared plans; sustained double-digit steal means the host is oversold, and the only fixes are another node or a real 1:1 plan. The provider cannot hide this metric: the hypervisor writes it into the guest's own accounting. Containers differ: inside LXC or OpenVZ the st column usually stays at zero while you are throttled; where the runtime exposes it, cat /sys/fs/cgroup/cpu.stat (cgroup v2) shows nr_throttled and throttled_usec climbing instead.

When "VDS" is just marketing

Because the label is unregulated, read the plan page for the signals that describe the architecture:

• "vCPU" without a ratio. A reserved plan says "dedicated cores" or "1 vCPU = 1 thread". If support cannot state the vCPU-to-thread ratio, assume it is shared.
• "Guaranteed RAM" next to "burst RAM". This is OpenVZ vocabulary for a container with a soft limit, not a VM with committed memory.
• No custom ISO, no kernel choice, no arbitrary reinstall. Those restrictions come from sharing the host kernel.
• "Semi-dedicated" or "hybrid" in the name. Honest words for a shared plan with lower contention. Fine, just not a VDS.

Plenty of providers use VDS honestly; the checks below settle the question in under a minute.

How to check what you actually get

1. Identify the virtualisation layer

systemd-detect-virt
# typical answers: kvm, qemu, xen, vmware, microsoft, openvz, lxc, docker, none
systemd-detect-virt --container   # container type, or none

virt-what (run as root) gives the same answer on distributions without systemd. lscpu | grep -i hypervisor should print Hypervisor vendor: KVM on a KVM guest; in a container, lscpu shows the host's full core count instead of your allocation, and the presence of /proc/vz or /proc/user_beancounters is a clear OpenVZ marker.

2. Read the CPU model and count

nproc
grep -m1 'model name' /proc/cpuinfo
lscpu | grep -E '^(Model name|Socket|Core|Thread|CPU\(s\))'

nproc should equal what you bought. A model name of QEMU Virtual CPU or Common KVM processor means the host masks the real CPU behind a generic model, hiding newer instruction sets such as AVX; a real model such as AMD EPYC 7443P means host passthrough. Neither proves reservation, but a masked CPU hints at a host tuned for density.

3. Measure steal time under load

vmstat 1 5          # last column: st
head -1 /proc/stat  # cpu user nice system idle iowait irq softirq steal guest guest_nice
stress-ng --cpu $(nproc) --timeout 60s   # package stress-ng, then watch vmstat

Measure at a busy hour. If st stays near zero while every vCPU is pegged, the cores are effectively yours; repeat over a few days, since contention depends on who else shares the node.

4. Check nested virtualisation

grep -cE 'vmx|svm' /proc/cpuinfo   # more than 0: the virtualisation flag is exposed
ls -l /dev/kvm                     # appears once kvm_intel or kvm_amd is loaded
kvm-ok                             # Ubuntu: package cpu-checker

If the flag is missing, the host masks the CPU model or has nested virtualisation off, and nothing that needs a hypervisor will run inside the guest. A container never exposes it.

5. Look at the disk device

lsblk -d -o NAME,SIZE,ROTA,MODEL
cat /sys/block/vda/queue/rotational   # 0 = non-rotational

vda is a virtio block device, the normal KVM setup; sda with a QEMU HARDDISK model is emulated SATA, still a VM. Inside a container the root filesystem is often a ploop or simfs mount. On Windows guests, systeminfo | findstr /i hyper-v reports that a hypervisor has been detected.

Pricing tiers and use cases

• Container VPS ($2-6): static sites, small bots, a VPN endpoint, or anything where the kernel does not matter and occasional slowdowns are acceptable.
• Shared KVM VPS ($4-12): development and staging boxes, low-traffic applications that need their own kernel and tolerate bursts of steal.
• VDS with reserved KVM resources ($8-40): trading bots, game servers, databases, CI runners, 24/7 automation and anything latency-sensitive that runs at high CPU for hours.
• Dedicated server ($60-300+): sustained 100% CPU on many cores, large RAM, GPUs, your own hypervisor, or rules that forbid shared hardware. A bare-metal dedicated server with IPMI access is the step up when a VDS is no longer enough.

If the reserved tier fits your workload, that is what rdp.monster sells: a KVM VPS with reserved CPU and RAM, NVMe storage, full root or admin access, unlimited (fair-use) bandwidth, no KYC, and crypto accepted alongside cards and PayPal, from $8.99/month. The machine is delivered about 10 seconds after payment confirms, so you can run systemd-detect-virt and vmstat 1 on it yourself before trusting the label (the same checks this article recommends for any provider).

Frequently Asked Questions

Is a VDS the same as a VPS?

Technically both are virtual servers; VDS is meant to signal reserved, non-overcommitted resources.

Both are virtual servers on shared hardware. The difference is a promise, not a technology: a VDS is supposed to run as a full virtual machine (typically KVM) with CPU cores and RAM reserved for you, while a VPS may share those resources with other tenants or even be a container on the host's kernel. Because no standard enforces the term, some providers use VDS and VPS interchangeably. Verify with systemd-detect-virt, nproc and steal time rather than trusting the name.

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

Run systemd-detect-virt; it prints kvm, openvz, lxc or none in one line.

Run systemd-detect-virt: it prints kvm, qemu, openvz, lxc or none. Without systemd, install and run virt-what as root. Two more clues: lscpu | grep -i hypervisor shows Hypervisor vendor: KVM on a KVM guest, and the presence of /proc/vz or /proc/user_beancounters means OpenVZ. On a container, nproc and uname -r also reflect the host rather than your plan.

What is an acceptable CPU steal time on a virtual server?

Near zero on reserved plans; a few percent in bursts is tolerable, sustained double digits means an oversold host.

On a VDS with reserved cores, the st column of vmstat 1 should sit at or near 0 even under full load. On shared plans, occasional single-digit values during peaks are normal. Sustained values of ten percent or more mean the host is overcommitted and your vCPUs are waiting behind other tenants. There is no fix from inside the guest: ask the provider to migrate you to a quieter node, or move to a plan with a 1:1 vCPU-to-thread ratio.

Can I run Docker or a nested VM on a virtual dedicated server?

Docker yes on any KVM guest; nested VMs only if the host exposes the vmx or svm CPU flag.

On a KVM-based VDS, Docker works like on any Linux machine because you run your own kernel. Nested virtualisation (KVM, VirtualBox, Hyper-V inside the guest) requires the host to pass through the CPU's virtualisation extension: check with grep -cE 'vmx|svm' /proc/cpuinfo, and confirm that /dev/kvm appears after loading kvm_intel or kvm_amd. On OpenVZ or LXC containers, nested VMs are impossible and Docker depends entirely on what the host permits.