Cómo funciona un VPS por dentro: del hipervisor al disco

Cómo funciona un VPS: la respuesta corta

Cómo funciona un VPS se resume en una frase: un programa llamado hipervisor divide un servidor físico en varios servidores virtuales, y cada uno arranca su propio kernel, tiene su propia cuenta root, su propio disco y responde en su propia dirección IP. Lo que se reparte por debajo es el hardware: los núcleos de la CPU, la RAM física, el disco NVMe y la tarjeta de red son los mismos para todos los vecinos. Lo que no se reparte es el sistema operativo. Dentro de tu VPS no hay nadie más.

Esa última frase es la diferencia con el hosting compartido, y conviene tenerla en la cabeza en todo lo que sigue. Si todavía no tienes claro qué es un VPS como producto, qué es un VPS lo explica desde cero. Aquí vamos a lo que pasa por debajo.

El hosting compartido que ya conoces: un kernel para todos

En un hosting compartido hay un servidor físico con un solo sistema operativo, un solo Apache o LiteSpeed, una sola versión de PHP (o las pocas que el proveedor ha instalado) y un solo usuario root, que es el del proveedor. Tú eres una cuenta de usuario con un directorio, normalmente public_html, y un panel que te deja tocar lo que el proveedor ha decidido que puedes tocar.

Eso tiene consecuencias que seguramente ya has sufrido:

• No puedes abrir un puerto, porque el firewall no es tuyo.
• No puedes cargar un módulo del kernel ni cambiar un sysctl, porque el kernel no es tuyo.
• Si el script de un vecino se come la CPU, tu web va lenta, porque los dos procesos compiten en el mismo planificador y con el mismo peso.
• Si un vecino consigue una escalada de privilegios, llega a tus archivos, porque están en el mismo sistema de ficheros que los suyos.

Dibujado en texto, el hosting compartido es esto:

  [ tu web ]   [ web del vecino ]   [ otra web ]   ... y cientos más
  -------------------------------------------------------------------
     un solo kernel, un solo Apache/PHP, un solo root (el del proveedor)
  -------------------------------------------------------------------
     hardware: CPU, RAM, disco, tarjeta de red

Solo hay una capa de separación entre tú y el vecino, y es la de usuarios de Linux. Funciona, pero es fina.

Qué hace el hipervisor en un VPS

El hipervisor es el programa que hace que un servidor físico parezca varios. En la mayoría de proveedores es KVM (Kernel-based Virtual Machine), un módulo del kernel de Linux que convierte al propio kernel del host en hipervisor. KVM se apoya en las extensiones de virtualización de la CPU, Intel VT-x o AMD-V, que añaden un modo de ejecución para invitados. En ese modo, el kernel de tu VPS ejecuta instrucciones normales directamente en el procesador, a velocidad nativa. Solo cuando intenta hacer algo privilegiado, como hablar con un dispositivo o cambiar sus tablas de páginas, la CPU devuelve el control al hipervisor. Ese salto se llama VM exit, y reducir cuántos ocurren es casi todo el trabajo de rendimiento en virtualización.

KVM solo se ocupa de la CPU y de la memoria. Los dispositivos los pone QEMU, un proceso normal del host. Visto desde el host, cada VPS es un proceso qemu-system-x86_64 con unos cuantos hilos: uno por cada vCPU y unos más para el disco y la red. Si el proveedor ejecuta ps en el host, tu servidor entero aparece como una línea.

Los dispositivos que ve tu VPS no imitan a tarjetas reales. Son dispositivos virtio, un estándar de paravirtualización: el kernel invitado sabe que está virtualizado y, en lugar de fingir que habla con una tarjeta de red física, usa una cola en memoria compartida con el host. Por eso tu disco se llama /dev/vda y no /dev/sda, y por eso el driver de red se llama virtio_net.

Existen alternativas. Xen usa un diseño parecido con un dominio de control separado. VMware ESXi y Hyper-V son hipervisores comerciales con la misma idea. Y luego están los contenedores de sistema, LXC u OpenVZ, que no son máquinas virtuales: comparten el kernel del host, igual que el hosting compartido, aunque con mejor aislamiento de recursos. Las diferencias prácticas entre esas opciones están en KVM frente a Xen y LXC en un VPS.

Puedes comprobar qué tienes debajo desde dentro del servidor:

systemd-detect-virt
lscpu | grep -i hypervisor
ls /sys/bus/virtio/devices

En un VPS KVM, systemd-detect-virt imprime kvm, lscpu muestra una línea Hypervisor vendor: KVM, y el directorio de virtio lista varios dispositivos (virtio0, virtio1 y así). En un contenedor, systemd-detect-virt imprime lxc u openvz, y el directorio de virtio está vacío o no existe, porque no hay hardware virtual: hay un kernel prestado.

El dibujo completo de un VPS

  [ tu VPS ]          [ VPS del vecino ]     [ otro VPS ]
  kernel propio       kernel propio          kernel propio
  root propio         root propio            root propio
  IP propia           IP propia              IP propia
  /dev/vda propio     /dev/vda propio        /dev/vda propio
  ----------------------------------------------------------
       QEMU: un proceso por VPS, dispositivos virtio
  ----------------------------------------------------------
       KVM dentro del kernel del host: reparte CPU y RAM
  ----------------------------------------------------------
       hardware: núcleos, RAM, NVMe, tarjeta de red

Compáralo con el dibujo del hosting compartido. Allí, la línea que separaba tu web de la del vecino era una cuenta de usuario. Aquí es un kernel entero, ejecutado en un modo de CPU que el propio hardware vigila.

Qué es tuyo y qué se comparte

Es tuyo todo lo que queda por encima del hipervisor:

• El kernel. Eliges la distribución, actualizas cuando quieres, cargas módulos y cambias cualquier sysctl.
• La cuenta root y el resto de usuarios. Nadie más tiene sesión en tu sistema.
• El sistema de ficheros completo, desde /.
• La dirección IP pública, la tabla de rutas y el firewall. Abres el puerto que quieras.
• La RAM asignada. Un VPS de 4 GB tiene 4 GB de memoria física desde el punto de vista del invitado, y su kernel la gestiona como en un servidor real.

Se comparte todo lo que queda por debajo:

• Los núcleos físicos de la CPU. Tus vCPU son hilos que esperan turno en el planificador del host.
• El disco físico. Tus IOPS (operaciones de entrada/salida por segundo) y tu ancho de banda de disco salen del mismo NVMe que los del vecino.
• La tarjeta de red y su enlace de subida. Un vecino descargando a tope reduce lo que queda para ti.
• El kernel del host y el propio hipervisor. Un fallo ahí afecta a todos los invitados a la vez.

Fíjate en que la lista de lo tuyo es, punto por punto, la lista de lo que el hosting compartido no te daba. Esa es la razón de que el salto de hosting compartido a VPS cambie tanto lo que puedes ejecutar, y de que lo que un VPS te da de verdad sea sobre todo control, y solo después rendimiento.

Por qué «2 vCPU» no son dos núcleos

Una vCPU (CPU virtual) es un hilo del proceso QEMU. Cuando tu kernel quiere ejecutar algo en su «CPU 0», el planificador del host tiene que colocar ese hilo en un núcleo físico libre. Si el host tiene 64 hilos de hardware y el proveedor ha vendido 200 vCPU entre todos los VPS de esa máquina, las 200 no pueden ejecutarse a la vez. Eso se llama sobresuscripción, y es la norma en el sector, porque la mayoría de servidores están ociosos la mayor parte del tiempo.

Cuando tu vCPU quiere correr y no hay núcleo libre, espera. Tu kernel no ve esa espera como CPU ocupada, porque desde dentro no ha ejecutado nada. La ve como tiempo que ha desaparecido. Ese tiempo se llama steal time (tiempo robado). El kernel invitado lo lee del hipervisor y lo muestra como st en top y en vmstat:

vmstat 1 5

La última columna, st, es el porcentaje de tiempo en que tu vCPU quería ejecutarse y el host se la dio a otro invitado. Un st de 0 o 1 es normal. Un st de 20 sostenido significa que la máquina física está saturada y que tu servidor va lento aunque us y sy estén bajos. Cómo medirlo bien y qué hacer cuando ocurre está en el steal time y el problema del vecino ruidoso.

En el hosting compartido este mismo problema existe, pero sin contador. Tu PHP y el del vecino son procesos del mismo kernel, así que tu proceso simplemente tarda más, y no hay ningún número que te diga por qué.

Una consecuencia menos obvia: dos vCPU tampoco garantizan dos núcleos distintos, ni el mismo socket, ni la misma caché. El host las coloca donde hay hueco en cada instante. Por eso un programa que escala mal con hilos puede rendir peor de lo que esperas en un VPS grande, y por eso medir con tu propia carga vale más que leer la ficha del plan.

Cómo funciona el disco: una imagen, no una partición

Tu /dev/vda es, en el host, un archivo o un volumen lógico: una imagen qcow2 o raw en un sistema de ficheros, un volumen LVM, o un bloque en un almacenamiento distribuido como Ceph. Cuando tu kernel escribe un sector, la escritura pasa por el driver virtio_blk, entra en una cola compartida con QEMU, y QEMU la convierte en una escritura sobre ese archivo o volumen. Desde dentro parece un disco. Desde fuera es un archivo grande que el proveedor puede copiar, mover, abrir o borrar.

Que sea un archivo trae dos cosas. La primera es el aprovisionamiento fino: una imagen de 80 GB con 10 GB usados ocupa unos 10 GB en el host, y crece según escribes. La segunda es que el ancho de banda del NVMe físico se reparte entre todas las imágenes que viven en él. Si el vecino lanza una copia de 200 GB, tus IOPS bajan mientras dura. Puedes ver tu dispositivo con:

lsblk -d -o NAME,SIZE,ROTA,TYPE

ROTA en 0 quiere decir que el host declara el disco como no rotativo, es decir, SSD o NVMe. Lo que no te dice es cuántos vecinos escriben en él ni con qué latencia responde hoy. Para eso están las pruebas con fio y, a largo plazo, vigilar la salud y la latencia del disco.

Qué es un snapshot

Un snapshot congela la imagen del disco en un instante. No copia los datos. La imagen usa copy-on-write (copiar al escribir): al crear el snapshot, el hipervisor marca los bloques actuales como de solo lectura y empieza a escribir los cambios nuevos en una capa aparte. Crear uno tarda segundos aunque el disco tenga cientos de GB, porque no se mueve nada. Restaurarlo es descartar la capa nueva y volver a apuntar a la vieja.

Dos cosas que un snapshot no es. No es una copia de seguridad, porque vive en el mismo disco físico y en el mismo host que tu VPS: si ese NVMe muere, mueren los dos. Y no es consistente por sí mismo: un snapshot tomado mientras el VPS escribe equivale a tirar del cable de corriente en ese instante. Un sistema de ficheros con journal como ext4 se recupera, pero una base de datos puede quedarse con una transacción a medias. Para eso existe qemu-guest-agent. Instalado dentro del VPS, permite al host pedir un fsfreeze justo antes del snapshot, de modo que el kernel invitado vacíe sus buffers y detenga las escrituras un momento. Primero comprueba que el canal del agente existe:

ls /dev/virtio-ports/

Si lista org.qemu.guest_agent.0, el canal está y puedes instalar el agente:

sudo apt install -y qemu-guest-agent
sudo systemctl enable --now qemu-guest-agent
systemctl is-active qemu-guest-agent

is-active debe responder active. Si el primer ls no muestra nada, el proveedor no ha expuesto el canal a tu VPS; el agente no tiene con quién hablar, no arranca, y los snapshots seguirán siendo del tipo «cable de corriente».

Qué es una migración en vivo

La migración en vivo mueve tu VPS de un host físico a otro sin apagarlo. El hipervisor de origen copia la RAM del invitado al host de destino mientras tu kernel sigue ejecutándose. Como el invitado sigue escribiendo en memoria, el origen lleva la cuenta de las páginas que han cambiado desde la última pasada (páginas sucias) y las vuelve a copiar, en varias rondas, hasta que quedan pocas. Entonces pausa la máquina unos milisegundos, copia esas últimas páginas junto con el estado de las vCPU, y la reanuda en el destino. El disco tiene que estar en un almacenamiento compartido que ambos hosts vean, o migrarse también con el mismo método de páginas sucias. La red se resuelve en el conmutador: el destino anuncia tu dirección MAC y el tráfico empieza a llegar allí, así que tu IP no cambia.

Desde dentro, tu uptime no se reinicia, las conexiones TCP sobreviven y, como mucho, notas una pausa de decenas de milisegundos. Así es como un proveedor vacía un host para cambiarle la RAM o parchear el kernel sin avisarte. En el hosting compartido no existe nada parecido: moverte de máquina es copiar archivos, exportar la base de datos, cambiar el DNS y esperar a que propague.

Hay una pista de que ha ocurrido. Si uptime dice 300 días pero el rendimiento cambió de golpe una noche, es probable que ahora vivas en otro host con otros vecinos. Eso no indica un fallo: la carga de la máquina nueva es distinta, y tu st también.

Por qué el proveedor puede reiniciar tu servidor pero no leer tu disco cifrado

El proveedor controla el hipervisor, y eso le da el mismo poder que tendría alguien con acceso físico a un servidor tuyo: puede pulsar el botón de reset (reiniciar las vCPU), apagar, arrancar desde una ISO, conectarse a la consola por VNC o puerto serie, y abrir el archivo de imagen del disco. No necesita tu contraseña de root para nada de eso, porque nada de eso pasa por tu kernel.

Lo que sí pasa por tu kernel es el cifrado del disco. Con LUKS (Linux Unified Key Setup), lo que hay en la imagen del host es texto cifrado, y la clave que lo abre solo existe en la RAM de tu VPS mientras está encendido. Si el proveedor copia la imagen, hace un snapshot, la migra a otro host o retira el NVMe al final de su vida útil, se lleva bytes que no puede leer. Ese es el caso que el cifrado resuelve: los datos en reposo.

Lo que el cifrado en reposo no resuelve es la RAM. La memoria de tu VPS es memoria del host, y un hipervisor hostil puede volcarla mientras la máquina corre, con la clave LUKS dentro. Por eso el modelo de confianza real es este: el proveedor puede leer tu VPS encendido si se lo propone, y no puede leer nada de una imagen de disco cifrada. Cerrar también el agujero de la RAM es lo que hacen AMD SEV-SNP e Intel TDX, que cifran la memoria del invitado con una clave que el host no tiene. La computación confidencial en un VPS explica hasta dónde llega eso y qué exige del proveedor.

Un detalle práctico del reinicio. Si tu disco raíz está cifrado con LUKS y el proveedor reinicia el host, tu VPS vuelve a arrancar y se queda esperando la contraseña en el initramfs. Nadie puede introducirla salvo tú, por consola o por un dropbear en el initramfs que escuche SSH. Hasta entonces el servidor está encendido y sin servicio. Eso es el diseño funcionando como debe, y hay que planearlo antes de cifrar.

En el hosting compartido esta pregunta ni se plantea. Tus archivos son archivos del sistema del proveedor, PHP los abre como un proceso del proveedor, y no hay ninguna capa donde una clave tuya pudiera vivir sin que el host la viera.

Qué cambia esto en la práctica

Con kernel propio, cosas que en el hosting compartido eran imposibles pasan a ser una orden de instalación: una versión de PHP distinta de la del vecino, Node o Go escuchando en el puerto que elijas, Docker (que necesita namespaces y cgroups del kernel), un túnel WireGuard (que carga un módulo), o incluso máquinas virtuales dentro de tu VPS si el proveedor expone VT-x al invitado. Con la parte compartida, cosas que en el hosting compartido eran invisibles pasan a tener un número: st para la CPU, la latencia de fio para el disco, iperf3 para la red y wa para saber cuál de los dos te frena.

Y con la separación por hipervisor en lugar de por usuario, la pregunta de seguridad cambia. Deja de ser «¿confío en los otros clientes de este servidor?» y pasa a ser «¿confío en KVM y en el proveedor?». Si un VPS es seguro depende de esa segunda pregunta, y de lo que hagas tú con root. Si además dudas entre un VPS y una VM en una nube grande, o no sabes dónde encaja una VPC, la diferencia entre VPS, VM y VPC va sobre todo de quién gestiona cada capa del dibujo de arriba.

FAQ

¿Un VPS con 2 vCPU tiene dos núcleos físicos para él solo?

No. Cada vCPU es un hilo que el planificador del host ejecuta en el núcleo que tenga libre en ese momento, y el host vende más vCPU de las que tiene núcleos. Cuando tu vCPU espera turno, ese tiempo aparece como st en vmstat o top. Un valor de 0 a 2 es normal; un valor alto y sostenido significa que la máquina física está saturada.

¿Puede el proveedor ver los archivos de mi VPS?

Puede abrir la imagen del disco desde el host sin pasar por tu root, así que un disco sin cifrar es legible. Con LUKS, la imagen contiene texto cifrado y la clave solo existe en la RAM del VPS mientras está encendido. El proveedor sigue pudiendo volcar esa RAM si quiere; lo que el cifrado protege es la imagen en reposo, los snapshots y las copias.

¿Un snapshot sirve como copia de seguridad?

No. El snapshot vive en el mismo disco físico y el mismo host que tu VPS, así que un fallo del NVMe se lleva los dos. Además, sin qemu-guest-agent y fsfreeze, se toma como si tiraras del cable de corriente. Úsalo para volver atrás tras un cambio arriesgado, y guarda la copia de seguridad real en otra máquina.

¿Cómo sé si mi VPS usa KVM u otro tipo de virtualización?

Ejecuta systemd-detect-virt. En KVM imprime kvm; en contenedores imprime lxc u openvz. Con lscpu | grep -i hypervisor verás el fabricante del hipervisor, y ls /sys/bus/virtio/devices lista los dispositivos virtio, que solo existen si hay hardware virtual y no un kernel prestado.

¿Por qué mi VPS va lento si top dice que la CPU está casi libre?

Mira la columna st. Si us y sy son bajos pero st es alto, tu vCPU quiere ejecutarse y el host se la está dando a otro invitado. La CPU de tu VPS está libre desde dentro y ocupada desde fuera. La otra causa habitual es el disco: un wa (iowait) alto significa que las escrituras esperan al NVMe compartido.