Cos'è un virtual dedicated server? VDS, VPS e dedicato

Che cos'è davvero un virtual dedicated server

Un virtual dedicated server (VDS) è una macchina virtuale ritagliata da un host fisico da un hypervisor (il più delle volte KVM su Linux, a volte Xen, VMware ESXi o Hyper-V) con una proprietà distintiva: le risorse indicate in fattura sono riservate. Due core significano due thread dell'host messi da parte per quella VM; 8 GB di RAM significano 8 GB che l'host non presta mai a un altro utente. Dentro la macchina hai il tuo kernel, la tua immagine disco, pieni diritti root o di Amministratore e qualsiasi sistema operativo che l'hypervisor sia in grado di avviare: un piccolo server dedicato dal punto di vista del guest, un inquilino tra molti che non competono mai per la stessa allocazione dal punto di vista dell'host.

Il termine esiste perché «VPS» è diventato troppo generico. Un VPS può essere qualsiasi cosa, da un container OpenVZ con RAM burstable a una macchina KVM su un host che vende lo stesso core fisico a sei clienti. «VDS» è stato adottato dai provider che volevano dire «questo non è sovravenduto». Dietro l'etichetta non c'è nessuno standard: nel mercato hosting di lingua russa VDS e VPS sono intercambiabili, e altrove alcuni provider rietichettano una semplice linea VPS perché VDS suona più vicino a dedicato. La parola ti dice l'intenzione; i comandi qui sotto ti dicono la verità.

VDS, VPS e server dedicato a confronto

I prodotti differiscono su due assi: il modo in cui la macchina è isolata (container, macchina virtuale o hardware fisico) e il fatto che le risorse siano riservate o condivise. Un VDS si colloca tra un VPS condiviso e un server dedicato su entrambi.

La colonna dei prezzi è una forchetta indicativa 2026 per i piani di ingresso, non un benchmark. Una VM con quattro core e 8 GB riservati non può essere venduta a 3 $ al mese; quando un «VDS» ha il prezzo di un container, di solito lo è.

Risorse riservate o condivise: dove sta la differenza

CPU. Su KVM ogni vCPU è un thread dell'host che lo scheduler Linux tratta come qualsiasi altro processo. Un host con 32 thread hardware può essere venduto come 32 vCPU (1:1, riservate) oppure come 128 vCPU (4:1, condivise). Niente dentro il guest mostra quel rapporto; diventa visibile solo come steal time e picchi di latenza quando i vicini sono carichi.

RAM. Gli host KVM sovrallocano la memoria in due modi: il driver virtio balloon permette all'host di recuperare le pagine che un guest non sta usando, e KSM (kernel samepage merging) deduplica le pagine identiche tra le VM. Su un piano riservato la memoria è impegnata all'avvio della VM e il balloon non viene mai gonfiato. Vedere virtio_balloon in lsmod dimostra la capacità, non l'uso: il driver è presente in quasi tutte le immagini cloud.

Storage. La riserva si estende raramente al disco; quasi tutti i provider condividono il backend di storage e al massimo limitano gli IOPS per VM. Ciò che cambia le prestazioni è il livello sottostante: un disco NVMe offre molti più IOPS e una latenza più bassa di un SSD SATA, e nessuna riserva di CPU compensa un disco lento sotto un database.

Rete. L'uplink è condiviso su tutto tranne un server dedicato con porta propria; banda «illimitata» significa illimitata secondo una politica di fair-use, non 1 Gbps garantito solo per te.

KVM contro virtualizzazione a container (OpenVZ, LXC)

Questa distinzione decide se un «VDS» possa essere dedicato o meno. KVM, Xen ed ESXi sono virtualizzazione hardware: VT-x o AMD-V permettono a ogni guest di eseguire il proprio kernel su hardware virtuale. OpenVZ, Virtuozzo, LXC e Docker sono virtualizzazione a livello di sistema operativo: ogni utente è un insieme di processi sul kernel dell'host, separati dai namespace e limitati dai cgroup. Proxmox li chiama «CT» e molti host low-cost li vendono come VPS. Le conseguenze:

• uname -r restituisce il kernel dell'host, che non hai scelto e non puoi aggiornare: storicamente gli host OpenVZ giravano su serie di kernel molto vecchie. Se non sei sicuro di che cosa giri davvero su una macchina, i comandi per trovare la versione del sistema operativo e del kernel su Linux, Windows e macOS richiedono pochi secondi.
• Non puoi caricare moduli del kernel: WireGuard, ZFS e qualsiasi cosa distribuita come .ko dipendono dall'host.
• La virtualizzazione annidata è impossibile, e Docker o systemd dentro il container funzionano solo se l'host lo consente.

Un guest KVM non ha nessuno di questi vincoli: si avvia da una ISO, esegue qualsiasi kernel e può esporre VT-x ai propri guest se l'host abilita la virtualizzazione annidata. Un vero VDS è quindi sempre una VM completa.

Vicini rumorosi e steal time

Un vicino rumoroso è un altro utente sullo stesso host il cui consumo di CPU, disco o rete erode il tuo. Su un host KVM sovrallocato lo scheduler mette la tua vCPU in coda dietro la loro, e il tempo in cui la tua vCPU era pronta ma in attesa viene riportato al guest come steal time. Linux lo espone come ottavo valore della riga cpu di /proc/stat, come colonna st di vmstat e top, e come %steal in mpstat e sar.

Una VM riservata dovrebbe mostrare uno steal pari o vicino a zero anche mentre i vicini lavorano a pieno regime. Qualche punto percentuale durante i picchi è normale sui piani condivisi; uno steal a due cifre prolungato significa che l'host è sovravenduto, e le uniche soluzioni sono un altro nodo o un vero piano 1:1. Il provider non può nascondere questa metrica: l'hypervisor la scrive nella contabilità stessa del guest. I container fanno eccezione: dentro LXC o OpenVZ la colonna st resta di solito a zero mentre vieni limitato; dove il runtime lo espone, cat /sys/fs/cgroup/cpu.stat (cgroup v2) mostra invece nr_throttled e throttled_usec in crescita.

Quando «VDS» è solo marketing

Poiché l'etichetta non è regolamentata, leggi la pagina del piano cercando i segnali che descrivono l'architettura:

• «vCPU» senza rapporto dichiarato. Un piano riservato dice «core dedicati» o «1 vCPU = 1 thread». Se il supporto non sa indicare il rapporto vCPU/thread, dai per scontato che sia condiviso.
• «RAM garantita» accanto a «RAM burst». È vocabolario OpenVZ per un container con un limite morbido, non una VM con memoria impegnata.
• Nessuna ISO personalizzata, nessuna scelta del kernel, nessuna reinstallazione libera. Queste restrizioni derivano dalla condivisione del kernel dell'host.
• «Semi-dedicato» o «ibrido» nel nome. Parole oneste per un piano condiviso con meno contesa: va benissimo, ma non è un VDS.

Molti provider usano il termine VDS onestamente; le verifiche qui sotto chiudono la questione in meno di un minuto.

Come verificare che cosa ottieni davvero

1. Identifica il livello di virtualizzazione

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

virt-what (eseguito come root) dà la stessa risposta sulle distribuzioni senza systemd. lscpu | grep -i hypervisor dovrebbe stampare Hypervisor vendor: KVM su un guest KVM; in un container, lscpu mostra il numero totale di core dell'host invece della tua allocazione, e la presenza di /proc/vz o /proc/user_beancounters è un chiaro indizio di OpenVZ.

2. Leggi il modello e il numero di CPU

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

nproc dovrebbe corrispondere a ciò che hai acquistato. Un nome di modello come QEMU Virtual CPU o Common KVM processor significa che l'host maschera la CPU reale dietro un modello generico, nascondendo i set di istruzioni più recenti come AVX; un modello reale come AMD EPYC 7443P indica il passthrough dell'host. Nessuno dei due dimostra la riserva, ma una CPU mascherata suggerisce un host ottimizzato per la densità.

3. Misura lo steal time sotto carico

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

Misura in un'ora di punta. Se st resta vicino a zero mentre ogni vCPU è al massimo, i core sono di fatto tuoi; ripeti la prova per qualche giorno, dato che la contesa dipende da chi altro condivide il nodo.

4. Verifica la virtualizzazione annidata

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

Se il flag manca, l'host maschera il modello di CPU oppure ha la virtualizzazione annidata disattivata, e nulla che richieda un hypervisor girerà dentro il guest. Un container non lo espone mai.

5. Guarda il dispositivo disco

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

vda è un dispositivo a blocchi virtio, la configurazione KVM abituale; sda con modello QEMU HARDDISK è SATA emulato, comunque una VM. Dentro un container il filesystem di root è spesso un mount ploop o simfs. Sui guest Windows, systeminfo | findstr /i hyper-v segnala che è stato rilevato un hypervisor.

Fasce di prezzo e casi d'uso

• VPS container ($2-6): siti statici, piccoli bot, un endpoint VPN, cioè tutto ciò in cui il kernel non conta e qualche rallentamento occasionale è accettabile.
• VPS KVM condiviso ($4-12): macchine di sviluppo e staging, applicazioni a basso traffico che hanno bisogno di un kernel proprio e tollerano picchi di steal.
• VDS con risorse KVM riservate ($8-40): bot di trading, server di gioco, database, runner CI, automazioni 24/7 e tutto ciò che è sensibile alla latenza e gira a CPU alta per ore.
• Server dedicato ($60-300+): CPU al 100% costante su molti core, RAM abbondante, GPU, il tuo hypervisor o regole che vietano l'hardware condiviso. Un server dedicato bare-metal con accesso IPMI è il passo successivo quando un VDS non basta più.

Se la fascia riservata è adatta al tuo carico di lavoro, è esattamente ciò che vende rdp.monster: un VPS KVM con CPU e RAM riservate, storage NVMe, accesso root o admin completo, banda illimitata (fair-use), senza KYC e con criptovalute accettate accanto a carte e PayPal, a partire da $8.99/mese. La macchina viene consegnata circa 10 secondi dopo la conferma del pagamento, così puoi eseguire tu stesso systemd-detect-virt e vmstat 1 prima di fidarti dell'etichetta, gli stessi controlli che questo articolo consiglia per qualsiasi provider.

Domande frequenti

Un VDS è la stessa cosa di un VPS?

Tecnicamente sono entrambi server virtuali; VDS vuole indicare risorse riservate e non sovrallocate.

Entrambi sono server virtuali su hardware condiviso. La differenza è una promessa, non una tecnologia: un VDS dovrebbe funzionare come macchina virtuale completa (tipicamente KVM) con core CPU e RAM riservati a te, mentre un VPS può condividere quelle risorse con altri utenti o essere addirittura un container sul kernel dell'host. Poiché nessuno standard impone il termine, alcuni provider usano VDS e VPS come sinonimi. Verifica con systemd-detect-virt, nproc e lo steal time invece di fidarti del nome.

Come faccio a sapere se il mio VPS è KVM o OpenVZ?

Esegui systemd-detect-virt; stampa kvm, openvz, lxc o none in una riga.

Esegui systemd-detect-virt: stampa kvm, qemu, openvz, lxc o none. Senza systemd, installa ed esegui virt-what come root. Altri due indizi: lscpu | grep -i hypervisor mostra Hypervisor vendor: KVM su un guest KVM, e la presenza di /proc/vz o /proc/user_beancounters significa OpenVZ. In un container, anche nproc e uname -r riflettono l'host invece del tuo piano.

Qual è uno steal time CPU accettabile su un server virtuale?

Vicino a zero sui piani riservati; qualche punto percentuale nei picchi è tollerabile, due cifre prolungate indicano un host sovravenduto.

Su un VDS con core riservati, la colonna st di vmstat 1 dovrebbe restare pari o vicina a 0 anche a pieno carico. Sui piani condivisi, valori occasionali a una cifra durante i picchi sono normali. Valori costanti del dieci percento o più significano che l'host è sovrallocato e le tue vCPU aspettano dietro altri utenti. Dall'interno del guest non c'è rimedio: chiedi al provider di migrarti su un nodo più tranquillo, oppure passa a un piano con rapporto vCPU/thread 1:1.

Posso usare Docker o una VM annidata su un virtual dedicated server?

Docker sì su qualsiasi guest KVM; VM annidate solo se l'host espone il flag CPU vmx o svm.

Su un VDS basato su KVM, Docker funziona come su qualsiasi macchina Linux perché esegui il tuo kernel. La virtualizzazione annidata (KVM, VirtualBox, Hyper-V dentro il guest) richiede che l'host esponga l'estensione di virtualizzazione della CPU: verifica con grep -cE 'vmx|svm' /proc/cpuinfo e conferma che /dev/kvm compaia dopo aver caricato kvm_intel o kvm_amd. Sui container OpenVZ o LXC le VM annidate sono impossibili e Docker dipende interamente da ciò che l'host permette.