“Virtual dedicated” is the most abused term in hosting. A 4 GB plan sold as VDS and a 4 GB plan sold as VPS often land on identical hardware with identical KVM steal times. The difference is what the hypervisor is contractually forbidden from doing to your guest: no CPU overcommit on your pinned cores, no memory balloon reclaim from your pages, and a block queue that no other tenant can enqueue into. That is a real product — but you should verify it rather than assume the label means it.
On a shared 8-vCPU host with 1:4 vCPU overcommit, a busy neighbour can push your steal time from 0.3% to 9% and your disk latency from 0.8 ms to 14 ms at p99, which is the difference between a 40 ms and a 300 ms API response. Hardware does not care what the invoice calls it. If you are sizing a first instance, the plan comparison at virtualserversvps.com is a sane baseline, but the numbers below are what you should test for yourself once the server exists.
What “dedicated” has to mean at the hypervisor
Three mechanisms produce the exclusivity vendors sell. CPU pinning (host-passthrough with a fixed affinity mask) binds guest vCPU threads to physical cores so the host scheduler cannot migrate you onto a core running another tenant. Memory reservation plus a memtune hard limit disables ballooning for the guest. And a dedicated virtio-blk queue or a passed-through NVMe namespace removes the shared request queue every other guest contends on.
Only the third is expensive for the host: block devices are the scarce resource on a SAN or a consumer NVMe array. That is why “VDS” plans differ from “VPS” on disk far more than on CPU — the RAM and vCPU numbers are the same, the queue is not. A vendor advertising dedicated cores while printing a shared vda is selling a scheduling policy, not hardware.
Reading the label: the four things to check in the plan page
- “Dedicated vCPU” vs “fair share”. Any plan using the words fair share, burst, or CPU credits is overcommitted by design.
- Memory: “reserved” or “guaranteed”. If the plan says “up to 8 GB”, ballooning is in play and your RSS ceiling is a hope.
- Disk: IOPS number plus whether it is per-volume or per-host. A per-host number means you share it.
- Steal time SLA. Almost nobody publishes one. That omission is itself the answer.
Ask support in writing: “are my vCPUs pinned to distinct physical cores, and is my block device on a queue no other guest shares?” A one-sentence answer without hedging is usually true, because a lie here is provable in ten minutes from inside the guest. A marketing paragraph is not an answer.
Testing the CPU claim on a running instance
Steal time is the first number to read. Run mpstat -P ALL 2 15 and look at %steal per core. Under 0.5% sustained on a 4-vCPU guest with a real workload is consistent with a pinned allocation; 5% or more in a spike pattern matching other tenants’ bursts is not.
Second, check topology. lscpu on a pinned allocation typically shows host-passthrough, so flags include avx512f. A generic qemu64 model is not proof of overcommit, but it is a hint the vCPUs are emulated for portability rather than dedicated for performance.
mpstat -P ALL 2 15 | tail -n +4
# %steal column: sustained >2% on any core = not dedicated
# then confirm the topology is not 4 vCPU on 1 physical core
lscpu | egrep 'Model name|Thread|Core|Socket'
grep -E 'steal' /proc/statTesting exclusive memory
Commit the full allocation and watch what the kernel is allowed to keep. Write 95% of RAM into /dev/shm, then read /proc/meminfo. On a ballooned guest, MemAvailable collapses as the balloon inflates to reclaim pages the host wants back.
The tell for dedicated memory is that the allocation survives a quiet hour. Write the buffer, leave it 45 minutes, and confirm Shmem in /proc/meminfo is unchanged. On an unreserved plan a neighbour’s spike trims yours by 15–30%, which your application sees as a cold cache, not an error.
Testing the disk queue claim
This is where the premium lives. Run fio with four 4 KB random-read jobs at --iodepth=32 for 60 seconds and record IOPS and p99.9. A dedicated queue on NVMe gives tight tails: 120k IOPS with p99.9 near 400 µs. A shared queue on the same nominal hardware gives the same median and a p99.9 of 6–12 ms.
The queue-depth signature is the giveaway. On a shared queue, iostat -x 1 shows aqu-sz climbing well above your own submitted depth, because the host queue includes everyone else’s I/O.
| Metric | Shared VPS (expected) | True VDS (expected) |
|---|---|---|
| Sustained %steal | 1–9% | <0.5% |
| 4K rand-read p99.9 | 6–12 ms | 0.4–1.0 ms |
aqu-sz vs own depth | 2–5× higher | ≈ submitted depth |
| Memory after 45 min idle | trimmed 15–30% | unchanged |
| Sequential 1 MB write | 180–400 MB/s | 1.5–3 GB/s |
Matching the workload to the claim
The premium pays back where p99 latency is the product: transactional databases, synchronous fsync on small writes, JVM services where a 300 ms GC pause plus 9% steal becomes a timeout, and CI runners where compile time is billed. It rarely pays for a CDN-fronted static site or a Redis cache at 90% hits.
The rule is blunt: if more than 5% of revenue depends on the 99th percentile of a request touching disk, the VDS premium of 1.6–2.2× is cheap. If p99 sits under your SLO with 3× headroom, you are insuring against a risk you have absorbed. Measure first, buy the number.
Where vendors blur the line
Two legitimate configurations get labelled VDS: physically partitioned hosts virtualised into one or two guests, and a “dedicated host” SKU where the whole machine is yours. The illegitimate one is a shared plan with a priority weight — a cpu.weight of 300 instead of 100, an advantage that evaporates the moment a second high-weight tenant lands. You cannot see the tenant list, but you can see steal time smooth for a month and then jagged for a week, with no change on your side.
A 30-minute acceptance test
Run this once, record the output, re-run 30 days later. If p99.9 on 4K random reads has moved more than 2× with no workload change, a neighbour arrived and the queue was never exclusive.
That is the whole point of the “virtual dedicated” category: it is a promise about the p99, not the median. Median performance on shared hardware is almost always fine, which is why benchmarks look identical and production does not. For a first deployment you can rent by the hour and run the acceptance test above; a plan that exposes pinned cores and a non-shared queue is worth the premium only if the numbers hold on the second run, and you will know within a day whether they do.
Leave a Reply
You must be logged in to post a comment.