¿Qué es un servidor dedicado virtual? VDS vs VPS vs dedicado

Qué es realmente un servidor dedicado virtual

Un servidor dedicado virtual (VDS) es una máquina virtual creada sobre un host físico por un hipervisor (casi siempre KVM en Linux, a veces Xen, VMware ESXi o Hyper-V) con una propiedad que lo define: los recursos que figuran en la factura están reservados. Dos núcleos significan dos hilos del host apartados para esa VM; 8 GB de RAM significan 8 GB que el host nunca presta a otro inquilino. Dentro de la máquina dispones de tu propio kernel, tu propia imagen de disco, derechos completos de root o Administrador y cualquier sistema operativo que el hipervisor sea capaz de arrancar: desde el punto de vista del huésped, un pequeño servidor dedicado; desde el del host, un inquilino entre varios que nunca compiten por la misma asignación.

El término existe porque «VPS» se volvió demasiado amplio. Un VPS puede ser cualquier cosa, desde un contenedor OpenVZ con RAM en modo burst hasta una máquina KVM en un host que vende el mismo núcleo físico a seis clientes. «VDS» lo adoptaron los proveedores que querían decir «este no está sobrevendido». No hay ningún estándar detrás de la etiqueta: en el mercado de hosting ruso VDS y VPS son intercambiables, y algunos proveedores de otros países reetiquetan una gama de VPS normal porque VDS suena más cerca de dedicado. La palabra te dice la intención; los comandos de más abajo te dicen la verdad.

VDS frente a VPS y servidor dedicado

Los productos se diferencian en dos ejes: cómo se aísla la máquina (contenedor, máquina virtual o hardware físico) y si los recursos están reservados o compartidos. Un VDS se sitúa entre un VPS compartido y un servidor dedicado en ambos ejes.

La columna de precios es un rango orientativo de 2026 para planes de entrada, no una referencia. Una VM de cuatro núcleos y 8 GB reservados no se puede vender por 3 dólares al mes; cuando un «VDS» tiene precio de contenedor, normalmente lo es.

Recursos reservados frente a compartidos: dónde está la diferencia

CPU. En KVM, cada vCPU es un hilo del host que el planificador de Linux trata como cualquier otro proceso. Un host con 32 hilos de hardware puede venderse como 32 vCPU (1:1, reservadas) o como 128 vCPU (4:1, compartidas). Nada dentro del huésped muestra esa proporción; solo se hace visible en forma de steal time y picos de latencia cuando los vecinos están ocupados.

RAM. Los hosts KVM sobrevenden memoria de dos maneras: el driver virtio balloon permite al host recuperar páginas que el huésped no usa, y KSM (kernel samepage merging) deduplica páginas idénticas entre VM. En un plan reservado, la memoria se compromete al arrancar la VM y el balloon nunca se infla. Ver virtio_balloon en lsmod demuestra la capacidad, no el uso: el driver viene en casi todas las imágenes cloud.

Almacenamiento. La reserva rara vez llega al disco; casi todos los proveedores comparten el backend de almacenamiento y, como mucho, limitan las IOPS por VM. Lo que cambia el rendimiento es el nivel que hay debajo: un disco NVMe ofrece muchas más IOPS y menor latencia que un SSD SATA, y ninguna reserva de CPU compensa un disco lento bajo una base de datos.

Red. El enlace de subida se comparte en todo salvo en un servidor dedicado con su propio puerto; ancho de banda «ilimitado» significa ilimitado (fair-use), no 1 Gbps garantizado solo para ti.

KVM frente a virtualización por contenedores (OpenVZ, LXC)

Esta división decide si un «VDS» puede ser dedicado siquiera. KVM, Xen y ESXi son virtualización por hardware: VT-x o AMD-V permiten que cada huésped ejecute su propio kernel sobre hardware virtual. OpenVZ, Virtuozzo, LXC y Docker son virtualización a nivel de sistema operativo: cada inquilino es un conjunto de procesos sobre el kernel del host, separados por namespaces y limitados por cgroups. Proxmox los llama «CT» y muchos hosts de bajo coste los venden como VPS. Las consecuencias:

• uname -r devuelve el kernel del host, que no has elegido ni puedes actualizar. Históricamente los hosts OpenVZ funcionaban con series de kernel muy antiguas. Si no sabes con seguridad qué ejecuta una máquina, los comandos para ver la versión del SO y del kernel en Linux, Windows y macOS tardan segundos.
• No puedes cargar módulos del kernel: WireGuard, ZFS y todo lo que se distribuye como .ko dependen del host.
• La virtualización anidada es imposible, y Docker o systemd dentro del contenedor solo funcionan si el host lo permite.

Un huésped KVM no tiene ninguna de esas limitaciones: arranca desde una ISO, ejecuta cualquier kernel y puede exponer VT-x a sus propios huéspedes si el host permite la virtualización anidada. Por tanto, un VDS genuino siempre es una VM completa.

Vecinos ruidosos y steal time

Un vecino ruidoso es otro inquilino del mismo host cuyo uso de CPU, disco o red recorta el tuyo. En un host KVM sobrevendido, el planificador pone tu vCPU en cola detrás de las suyas, y el tiempo que tu vCPU pasó lista pero esperando se comunica al huésped como steal time. Linux lo expone como el octavo valor de la línea cpu de /proc/stat, como la columna st de vmstat y top, y como %steal en mpstat y sar.

Una VM reservada debería mostrar un steal cercano a cero incluso mientras sus vecinos trabajan a tope. Un pequeño porcentaje durante los picos es normal en planes compartidos; un steal sostenido de dos dígitos significa que el host está sobrevendido, y las únicas soluciones son otro nodo o un plan realmente 1:1. El proveedor no puede ocultar esta métrica: el hipervisor la escribe en la propia contabilidad del huésped. Los contenedores son distintos: dentro de LXC u OpenVZ la columna st suele quedarse en cero mientras te limitan; cuando el runtime lo expone, cat /sys/fs/cgroup/cpu.stat (cgroup v2) muestra nr_throttled y throttled_usec subiendo en su lugar.

Cuándo «VDS» es solo marketing

Como la etiqueta no está regulada, lee la página del plan buscando las señales que describen la arquitectura:

• «vCPU» sin proporción. Un plan reservado dice «núcleos dedicados» o «1 vCPU = 1 hilo». Si el soporte no sabe indicarte la proporción vCPU/hilo, da por hecho que es compartido.
• «RAM garantizada» junto a «RAM burst». Es vocabulario de OpenVZ para un contenedor con límite blando, no una VM con memoria comprometida.
• Sin ISO propia, sin elección de kernel, sin reinstalación libre. Esas restricciones vienen de compartir el kernel del host.
• «Semidedicado» o «híbrido» en el nombre. Palabras honestas para un plan compartido con menos contención: está bien, pero no es un VDS.

Muchos proveedores usan VDS con honestidad; las comprobaciones siguientes zanjan la cuestión en menos de un minuto.

Cómo comprobar lo que realmente tienes

1. Identifica la capa de virtualización

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

virt-what (ejecutado como root) da la misma respuesta en distribuciones sin systemd. lscpu | grep -i hypervisor debería imprimir Hypervisor vendor: KVM en un huésped KVM; en un contenedor, lscpu muestra el número total de núcleos del host en lugar de tu asignación, y la presencia de /proc/vz o /proc/user_beancounters es un indicio claro de OpenVZ.

2. Lee el modelo y el número de CPU

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

nproc debería coincidir con lo que has comprado. Un nombre de modelo como QEMU Virtual CPU o Common KVM processor significa que el host enmascara la CPU real tras un modelo genérico, ocultando juegos de instrucciones más recientes como AVX; un modelo real como AMD EPYC 7443P indica passthrough del host. Ninguno prueba la reserva, pero una CPU enmascarada apunta a un host ajustado para la densidad.

3. Mide el steal time bajo carga

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

Mide en una hora punta. Si st se mantiene cerca de cero mientras todas las vCPU están al máximo, los núcleos son efectivamente tuyos; repítelo durante unos días, ya que la contención depende de quién más comparta el nodo.

4. Comprueba la virtualización anidada

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

Si falta el flag, el host enmascara el modelo de CPU o tiene la virtualización anidada desactivada, y nada que necesite un hipervisor funcionará dentro del huésped. Un contenedor nunca lo expone.

5. Mira el dispositivo de disco

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

vda es un dispositivo de bloque virtio, la configuración habitual de KVM; sda con un modelo QEMU HARDDISK es SATA emulado, y sigue siendo una VM. Dentro de un contenedor, el sistema de archivos raíz suele ser un montaje ploop o simfs. En huéspedes Windows, systeminfo | findstr /i hyper-v informa de que se ha detectado un hipervisor.

Niveles de precio y casos de uso

• VPS en contenedor ($2-6): sitios estáticos, bots pequeños, un endpoint VPN, o cualquier cosa donde el kernel no importe y las ralentizaciones ocasionales sean aceptables.
• VPS KVM compartido ($4-12): máquinas de desarrollo y staging, aplicaciones de poco tráfico que necesitan su propio kernel y toleran picos de steal.
• VDS con recursos KVM reservados ($8-40): bots de trading, servidores de juegos, bases de datos, runners de CI, automatización 24/7 y todo lo sensible a la latencia que funcione con la CPU alta durante horas.
• Servidor dedicado ($60-300+): CPU al 100 % de forma sostenida en muchos núcleos, mucha RAM, GPU, tu propio hipervisor o normas que prohíben el hardware compartido. Un servidor dedicado bare-metal con acceso IPMI es el siguiente paso cuando un VDS ya no basta.

Si el nivel reservado encaja con tu carga de trabajo, eso es lo que vende rdp.monster: un VPS KVM con CPU y RAM reservadas, almacenamiento NVMe, acceso completo de root o administrador, ancho de banda ilimitado (fair-use), sin KYC y con criptomonedas aceptadas junto a tarjetas y PayPal, desde $8.99/mes. La máquina se entrega unos 10 segundos después de la confirmación del pago, así que puedes ejecutar tú mismo systemd-detect-virt y vmstat 1 antes de fiarte de la etiqueta, las mismas comprobaciones que este artículo recomienda para cualquier proveedor.

Preguntas frecuentes

¿Un VDS es lo mismo que un VPS?

Técnicamente ambos son servidores virtuales; VDS pretende indicar recursos reservados y sin sobreventa.

Ambos son servidores virtuales sobre hardware compartido. La diferencia es una promesa, no una tecnología: se supone que un VDS funciona como una máquina virtual completa (normalmente KVM) con núcleos de CPU y RAM reservados para ti, mientras que un VPS puede compartir esos recursos con otros inquilinos o incluso ser un contenedor sobre el kernel del host. Como ningún estándar regula el término, algunos proveedores usan VDS y VPS indistintamente. Verifícalo con systemd-detect-virt, nproc y el steal time en lugar de fiarte del nombre.

¿Cómo sé si mi VPS es KVM u OpenVZ?

Ejecuta systemd-detect-virt; imprime kvm, openvz, lxc o none en una sola línea.

Ejecuta systemd-detect-virt: imprime kvm, qemu, openvz, lxc o none. Sin systemd, instala y ejecuta virt-what como root. Dos pistas más: lscpu | grep -i hypervisor muestra Hypervisor vendor: KVM en un huésped KVM, y la presencia de /proc/vz o /proc/user_beancounters significa OpenVZ. En un contenedor, nproc y uname -r también reflejan el host y no tu plan.

¿Qué steal time de CPU es aceptable en un servidor virtual?

Cercano a cero en planes reservados; unos pocos por ciento en picos es tolerable, dos dígitos sostenidos indican un host sobrevendido.

En un VDS con núcleos reservados, la columna st de vmstat 1 debería quedarse en 0 o cerca incluso a plena carga. En planes compartidos, valores puntuales de un dígito durante los picos son normales. Valores sostenidos del diez por ciento o más significan que el host está sobrevendido y que tus vCPU esperan detrás de otros inquilinos. No hay solución desde dentro del huésped: pide al proveedor que te migre a un nodo más tranquilo, o pásate a un plan con proporción 1:1 entre vCPU e hilos.

¿Puedo usar Docker o una VM anidada en un servidor dedicado virtual?

Docker sí en cualquier huésped KVM; las VM anidadas solo si el host expone el flag de CPU vmx o svm.

En un VDS basado en KVM, Docker funciona igual que en cualquier máquina Linux porque ejecutas tu propio kernel. La virtualización anidada (KVM, VirtualBox, Hyper-V dentro del huésped) exige que el host haga passthrough de la extensión de virtualización de la CPU: compruébalo con grep -cE 'vmx|svm' /proc/cpuinfo y confirma que /dev/kvm aparece tras cargar kvm_intel o kvm_amd. En contenedores OpenVZ o LXC, las VM anidadas son imposibles y Docker depende por completo de lo que permita el host.