Has instalado Proxmox VE. La interfaz web carga. Puedes crear una VM. Te sientes poderoso.
Luego un disco se llena a las 3 a. m., las copias de seguridad “tienen éxito” pero no se restauran, y alguien descubre que la interfaz de administración es accesible desde la red de invitados. Ese es el momento en que Proxmox deja de ser un juguete de laboratorio y se convierte en infraestructura. La buena noticia: los primeros 10 arreglos son en su mayoría aburridos, rápidos y extremadamente efectivos.
Contexto histórico rápido (porque explica los bordes filosos)
- Orígenes de Proxmox VE en Debian. Eso significa que obtienes la estabilidad y la cultura de empaquetado de Debian—y también la expectativa de que actúes como sysadmin, no como mago.
- KVM se convirtió en “el hipervisor de Linux” hace más de una década. Proxmox aprovecha esa madurez. La mayor parte de las rarezas que ves son de red/almacenamiento, no de KVM en sí.
- Los contenedores LXC son anteriores a Docker. LXC se acerca más a la semántica de “VM ligera”: excelente para servicios, pero heredas las restricciones de compartir kernel.
- ZFS no fue diseñado para “ups llené el pool”. Es un sistema de archivos transaccional que recompensa la planificación y castiga mentir sobre el espacio libre.
- La provisión fina precede al bombo de la nube. El overcommit siempre ha sido un truco contable con una factura física más tarde.
- Los sistemas de archivos en clúster y el quórum son disciplinas antiguas y delicadas. Corosync no es magia nueva; es la realidad de sistemas distribuidos con mejores herramientas.
- El “éxito” de una copia de seguridad ha sido engañoso desde la era de las cintas. Una marca verde significa “el trabajo se ejecutó”, no “los datos son recuperables”.
- “Infraestructura como mascotas” solía ser normal. Proxmox es lo bastante flexible para dejarte seguir haciéndolo. No lo hagas.
Una cita para tener en la pantalla, parafraseando una idea de John Allspaw: parafraseando la idea: la fiabilidad viene de diseñar pensando en fallos y aprender rápido, no de fingir que puedes eliminarlos.
1) Arreglar los repositorios de paquetes (y actualizar como un adulto)
Justo después de la instalación, Proxmox apunta al repositorio enterprise (que requiere suscripción) o a algo que heredaste de una guía en la que confías a medias. Tu primera tarea es hacer que las actualizaciones sean predecibles. La predictibilidad vence a las heroicas.
Tarea 1: Ver qué repositorios estás usando realmente
cr0x@server:~$ grep -R --line-number -E 'pve|proxmox|ceph' /etc/apt/sources.list /etc/apt/sources.list.d/*.list
/etc/apt/sources.list.d/pve-enterprise.list:1:deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise
/etc/apt/sources.list.d/ceph.list:1:deb http://download.proxmox.com/debian/ceph-quincy bookworm no-subscription
Qué significa la salida: Actualmente estás usando el repo enterprise para PVE (se requiere suscripción) y no-subscription para Ceph.
Decisión: Si no tienes suscripción, desactiva pve-enterprise y usa el repo no-subscription. Si tienes suscripción, conserva enterprise y elimina no-subscription para evitar procedencia mixta.
Tarea 2: Desactivar el repo enterprise (si no tienes suscripción)
cr0x@server:~$ sed -i 's/^deb /# deb /' /etc/apt/sources.list.d/pve-enterprise.list
cr0x@server:~$ cat /etc/apt/sources.list.d/pve-enterprise.list
# deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise
Qué significa la salida: Está comentado. APT no intentará acceder a enterprise y fallar con 401s.
Decisión: Añade el repo no-subscription para recibir actualizaciones de seguridad.
Tarea 3: Añadir el repo no-subscription (PVE)
cr0x@server:~$ echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" | tee /etc/apt/sources.list.d/pve-no-subscription.list
deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription
cr0x@server:~$ apt-get update
Hit:1 http://download.proxmox.com/debian/pve bookworm InRelease
Hit:2 http://security.debian.org/debian-security bookworm-security InRelease
Reading package lists... Done
Qué significa la salida: Índices actualizados correctamente. No hay spam rojo “401 Unauthorized”.
Decisión: Parchea el host ahora, luego adopta una rutina (semanal está bien para la mayoría de pequeñas instalaciones; diaria para entornos expuestos).
Tarea 4: Comprobar qué se actualizará antes de hacerlo
cr0x@server:~$ apt-get -s dist-upgrade | sed -n '1,25p'
Reading package lists... Done
Building dependency tree... Done
Calculating upgrade... Done
The following packages will be upgraded:
pve-kernel-6.8.12-4-pve proxmox-ve pve-manager ...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Qué significa la salida: El modo simulación (-s) muestra el impacto. Las actualizaciones de kernel implican reinicios. Las actualizaciones de gestión pueden reiniciar servicios.
Decisión: Si esto es producción, programa la ventana de reinicio. Si es tu primer nodo, reinicia ahora y aprende el ciclo.
Regla opinada: No “configures y olvides” las actualizaciones del host. Proxmox es un plano de control. Los planos de control sin parchear son lo que te gana trabajo el fin de semana.
2) Restringir usuarios, dominios y permisos
Proxmox facilita ejecutar todo como root@pam. Eso también es cómo terminas con una contraseña compartida en un post-it. Usa cuentas con nombre y el principio de privilegio mínimo. Tu yo del futuro te enviará una tarjeta de agradecimiento.
Tarea 5: Listar usuarios y ver quién puede hacer qué
cr0x@server:~$ pveum user list
┌─────────────┬───────────┬───────────┬──────────────────────┐
│ userid │ enable │ expire │ firstname │
╞═════════════╪═══════════╪═══════════╪══════════════════════╡
│ root@pam │ 1 │ │ │
│ alice@pam │ 1 │ │ Alice │
└─────────────┴───────────┴───────────┴──────────────────────┘
cr0x@server:~$ pveum acl list | head
/:
user:root@pam role:Administrator
Qué significa la salida: Solo root@pam es admin explícito. Eso es típico en instalaciones nuevas.
Decisión: Crea un usuario administrador con nombre, luego restringe el uso de root para casos de emergencia.
Tarea 6: Crear un admin con nombre y requerir MFA en el borde (o al menos autenticación fuerte)
cr0x@server:~$ pveum user add sre-admin@pam --comment "Named admin account"
cr0x@server:~$ pveum passwd sre-admin@pam
Enter new password:
Retype new password:
cr0x@server:~$ pveum aclmod / -user sre-admin@pam -role Administrator
cr0x@server:~$ pveum acl list | head -n 10
/:
user:root@pam role:Administrator
user:sre-admin@pam role:Administrator
Qué significa la salida: Ahora tienes un segundo admin, lo que te permite dejar de usar root a diario.
Decisión: Mantén root@pam para emergencias y automatización que realmente lo necesite, no para clics ocasionales.
Mini-historia corporativa: incidente causado por una suposición equivocada
En una empresa mediana, un nuevo administrador de virtualización supuso “la UI de Proxmox está en la LAN de gestión, así que nadie no confiable puede acceder.” Era verdad en su cabeza, no en los switches.
Un contratista que se conectó a un puerto libre acabó en la misma VLAN que los hipervisores. Nadie lo notó porque “todo funcionaba”, y el diagrama de red se actualizó por última vez cuando la gente aún los imprimía.
No fueron atacados por un estado-nación. Les tocó un escáner aburrido que encontró la página de login y forzó por fuerza bruta una contraseña root débil compartida. El atacante creó una VM, la usó como pivote, y la primera señal fue un pico en el tráfico saliente.
La solución no fue exótica: separar la red de gestión, restringir el acceso a la UI, deshabilitar SSH por contraseña para root y dejar de compartir credenciales. La lección dolorosa fue que las asunciones no son controles.
3) Endurecer SSH y dejar de entrar como root
SSH es la llave maestra. Trátala como tal. Quieres: autenticación por clave, sin login root y un rastro que puedas seguir.
Tarea 7: Revisar la configuración SSH actual que importa
cr0x@server:~$ sshd -T | egrep '^(permitrootlogin|passwordauthentication|pubkeyauthentication|kbdinteractiveauthentication) '
permitrootlogin yes
passwordauthentication yes
pubkeyauthentication yes
kbdinteractiveauthentication no
Qué significa la salida: Se permite login root y autenticación por contraseña. Es cómodo; también es una invitación.
Decisión: Deshabilita el login root y la autenticación por contraseña una vez que tengas claves funcionando para un usuario con nombre.
Tarea 8: Aplicar un drop-in básico de endurecimiento
cr0x@server:~$ install -d -m 0755 /etc/ssh/sshd_config.d
cr0x@server:~$ cat > /etc/ssh/sshd_config.d/99-hardening.conf <<'EOF'
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
EOF
cr0x@server:~$ sshd -t && systemctl reload ssh
Qué significa la salida: sshd -t valida la sintaxis. Reload aplica sin cerrar sesiones existentes.
Decisión: Prueba una nueva sesión SSH antes de cerrar la actual. Bloquearte es un rito de paso; también es evitable.
Tarea 9: Confirmar que puedes seguir entrando (y que root no puede)
cr0x@server:~$ ssh -o PreferredAuthentications=publickey sre-admin@192.0.2.10 'id'
uid=1001(sre-admin) gid=1001(sre-admin) groups=1001(sre-admin)
cr0x@server:~$ ssh -o PreferredAuthentications=password root@192.0.2.10 'true'
root@192.0.2.10: Permission denied (publickey).
Qué significa la salida: El admin con nombre funciona con claves. Root está bloqueado.
Decisión: Mantén acceso por consola (IPMI/iKVM/physical) como tu vía de ruptura de cristal. No confíes en SSH como única puerta.
4) Activar el firewall (de la manera correcta)
Proxmox tiene un firewall decente. No es mágico. El modo de fallo más común es activarlo en todos lados sin entender el orden de reglas y quedarte fuera.
Broma breve #1: Los firewalls son como los cinturones de seguridad: te arrepientes de no usarlos en los momentos emocionantes.
Tarea 10: Ver estado y reglas actuales del firewall
cr0x@server:~$ pve-firewall status
Status: disabled/running (cluster: disabled)
cr0x@server:~$ pve-firewall localnet
192.0.2.0/24
Qué significa la salida: El demonio del firewall está corriendo pero no hace cumplir reglas. localnet es lo que Proxmox trata como “confiable”. Si eso es incorrecto, tus reglas estarán mal.
Decisión: Define la(s) subred(es) de gestión como localnet, luego habilita el firewall a nivel del datacenter y, después, a nivel de nodo—con cuidado.
Tarea 11: Validar la IP de gestión y la subred donde está
cr0x@server:~$ ip -br addr show vmbr0
vmbr0 UP 192.0.2.10/24 fe80::5054:ff:fe12:3456/64
cr0x@server:~$ ip route show default
default via 192.0.2.1 dev vmbr0
Qué significa la salida: Tu interfaz de gestión está en vmbr0 con 192.0.2.10/24. La ruta por defecto también está ahí.
Decisión: Si los invitados comparten esta red, detente y rediseña. La gestión no debería ser “otra VLAN” a la que las VMs se conectan a la ligera.
Tarea 12: Habilitar firewall y permitir solo lo necesario al host
cr0x@server:~$ pvesh set /cluster/firewall/options --enable 1
cr0x@server:~$ pvesh set /nodes/$(hostname)/firewall/options --enable 1
cr0x@server:~$ pvesh get /nodes/$(hostname)/firewall/options
┌────────────┬────────┐
│ key │ value │
╞════════════╪════════╡
│ enable │ 1 │
└────────────┴────────┘
Qué significa la salida: El firewall está habilitado a nivel de clúster y en el nodo. Aún necesitas reglas explícitas, o podrías romper el acceso según los valores por defecto.
Decisión: Añade una regla de permitir gestión para la UI web y SSH desde localnet, luego una política por defecto de denegar todo lo demás.
Tarea 13: Confirmar puertos en escucha y que solo sean accesibles desde donde toca
cr0x@server:~$ ss -lntp | egrep '(:22|:8006)\s'
LISTEN 0 128 0.0.0.0:22 0.0.0.0:* users:(("sshd",pid=1123,fd=3))
LISTEN 0 4096 0.0.0.0:8006 0.0.0.0:* users:(("pveproxy",pid=1876,fd=6))
Qué significa la salida: SSH y el proxy web de Proxmox están enlazados en todas las direcciones IPv4. Eso es normal en un nodo con una sola interfaz.
Decisión: Si no puedes aislar por binding, aísla con diseño de red y reglas de firewall. “Enlazado a 0.0.0.0” está bien si tu firewall y VLANs son correctos.
5) Corregir la red de gestión y los bridges
La mayor parte del dolor con Proxmox es en realidad dolor de redes Linux con una buena presentación. Los bridges son poderosos; también honestos. Si tu red física está desordenada, Proxmox la reproducirá fielmente a velocidad de línea.
Tarea 14: Inspeccionar la configuración real del bridge que usa Proxmox
cr0x@server:~$ cat /etc/network/interfaces
auto lo
iface lo inet loopback
auto enp3s0
iface enp3s0 inet manual
auto vmbr0
iface vmbr0 inet static
address 192.0.2.10/24
gateway 192.0.2.1
bridge-ports enp3s0
bridge-stp off
bridge-fd 0
Qué significa la salida: Simple: una NIC, un bridge. Los invitados unidos a vmbr0 están en el mismo L2 que tu interfaz de gestión.
Decisión: Si esto es algo más que un laboratorio, separa el tráfico de gestión y el de invitados con VLANs o una segunda NIC. Como mínimo: gestión en una VLAN etiquetada a la que solo TI tenga acceso.
Tarea 15: Comprobar salud del enlace y problemas del driver (victorias baratas)
cr0x@server:~$ ethtool enp3s0 | egrep 'Speed|Duplex|Link detected'
Speed: 1000Mb/s
Duplex: Full
Link detected: yes
Qué significa la salida: Estás a 1GbE. Está bien para un homelab; también es cómo accidentalmente construyes un problema de “almacenamiento lento” que en realidad es “red lenta”.
Decisión: Si planeas almacenamiento compartido o backups por red, 10GbE no es lujo. Es margen.
6) Hora, NTP y certificados: aburrido hasta que te quema
Si la hora está desincronizada, TLS se queja, los clústeres se vuelven raros y los registros se convierten en ficción. Si los certificados son un desastre, tu navegador te entrena a ignorar advertencias—hasta la vez en que no debes hacerlo.
Tarea 16: Verificar sincronización horaria y zona
cr0x@server:~$ timedatectl
Local time: Sun 2025-12-28 11:02:15 UTC
Universal time: Sun 2025-12-28 11:02:15 UTC
RTC time: Sun 2025-12-28 11:02:16
Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
Qué significa la salida: El reloj está sincronizado. UTC es un buen valor por defecto para servidores salvo que tengas una razón fuerte para no usarlo.
Decisión: Mantén los hosts en UTC. Ajusta la visualización en tu herramienta de monitorización si los humanos insisten.
Tarea 17: Comprobar estado de certificados (y evitar enseñar malos hábitos)
cr0x@server:~$ pvecm status 2>/dev/null | head -n 5
Cluster information
-------------------
Name: pve-cluster
Config Version: 1
Transport: knet
Qué significa la salida: Si ya estás en clúster, la consistencia de certificados y nombres de host importa más. Incluso en un nodo único, mantén el hostname estable.
Decisión: No reinstales y renombres nodos a la ligera. Proxmox perdona, pero los clústeres recuerdan.
7) Elegir un diseño de almacenamiento que refleje la realidad
Las decisiones de almacenamiento son donde los principiantes quedan silenciosamente arruinados. Proxmox te permite construir algo que rinde en benchmarks y falla catastróficamente. Necesitas decidir: almacenamiento local vs compartido, ZFS vs LVM-thin, y dónde caen las copias de seguridad.
Tres patrones sensatos para principiantes
- Nodo único, discos locales: espejo ZFS para VMs + disco/dataset separado para backups (preferiblemente no en el mismo pool).
- Pequeño clúster sin almacenamiento compartido: ZFS local en cada nodo + backups a un Proxmox Backup Server (PBS) dedicado + aceptar que la migración en caliente necesita almacenamiento compartido o estrategias de replicación.
- Clúster con almacenamiento compartido: Ceph (mínimo 3 nodos para sensatez) o un SAN/NAS dedicado. Esto no es “día uno para principiantes” a menos que disfrutes sistemas distribuidos a las 2 a. m.
Tarea 18: Identificar tus discos y el stack de almacenamiento actual
cr0x@server:~$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
NAME SIZE TYPE FSTYPE MOUNTPOINTS
sda 447.1G disk
├─sda1 1007K part
├─sda2 1G part vfat /boot/efi
└─sda3 446.1G part zfs_member
sdb 3.6T disk
└─sdb1 3.6T part
Qué significa la salida: Tu pool del SO/VM está en ZFS (zfs_member). Tienes otro disco grande (sdb) que está sin usar o formateado en otro sitio.
Decisión: Usa sdb para backups, no para “espacio extra de VM”. Backups compitiendo con I/O de VM es cómo fabricas latencia.
Tarea 19: Comprobar salud del pool antes de confiar en él
cr0x@server:~$ zpool status
pool: rpool
state: ONLINE
config:
NAME STATE READ WRITE CKSUM
rpool ONLINE 0 0 0
sda3 ONLINE 0 0 0
errors: No known data errors
Qué significa la salida: El pool está online sin errores. También: es un disco único. Eso no es redundancia; es esperanza.
Decisión: Si esto es importante, réconstrúyelo como espejo. Un pool root ZFS en disco único está bien para laboratorio, no para la VM que paga la nómina.
Dato interesante: ZFS suma comprobaciones a cada bloque y puede autocorregirse—pero solo si le das una segunda copia (mirror/RAIDZ). En un disco único, puede detectar corrupción y luego encogerse de hombros.
8) Fundamentos de ZFS: qué tocar y qué dejar intacto
La afinación de ZFS tiene una cultura de aficionados. Parte es real. Mucha gente copia recetas de foros de 2016 a kernels de 2025. Tu trabajo es mantenerlo simple, medible y reversible.
Los valores por defecto de ZFS que no deberías combatir
- Deja que ARC se gestione solo a menos que tengas un problema específico de presión de memoria.
- No actives algoritmos de compresión aleatorios porque leíste que “son más rápidos.” Usa
lz4y sigue adelante. - No pongas un
recordsizegigante sin entender tu carga de trabajo. Las VMs son criaturas de I/O aleatorio.
Tarea 20: Confirmar propiedades clave del dataset ZFS para almacenamiento de VMs
cr0x@server:~$ zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool 98G 300G 96K /rpool
rpool/ROOT 12G 300G 96K /rpool/ROOT
rpool/data 72G 300G 96K /rpool/data
rpool/data/vm-100-disk-0 40G 300G 40G -
cr0x@server:~$ zfs get -o name,property,value compression,atime,recordsize,volblocksize rpool/data
NAME PROPERTY VALUE
rpool/data compression lz4
rpool/data atime off
rpool/data recordsize 128K
rpool/data volblocksize -
Qué significa la salida: lz4 y atime=off son buenos. recordsize en un dataset importa para ficheros; los ZVOLs usan volblocksize.
Decisión: Para discos de VM, céntrate en el tamaño de bloque de ZVOL en el momento de creación (a menudo 16K es un buen compromiso general para cargas mixtas). No cambies estas opciones sin medir.
Tarea 21: Comprobar espacio libre del pool y riesgo de fragmentación
cr0x@server:~$ zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH
rpool 446G 98G 348G - 12% 22% 1.00x ONLINE
Qué significa la salida: 22% usado está bien. El problema comienza cuando tratas “FREE” como gastable hasta cero.
Decisión: Mantén los pools ZFS por debajo de ~80% usados para rendimiento estable. Por debajo de ~70% si quieres menos sorpresas con snapshots y churn.
Tarea 22: Establecer una política explícita de refreservation/espacio para seguridad (opcional pero inteligente)
cr0x@server:~$ zfs set refreservation=20G rpool/data
cr0x@server:~$ zfs get refreservation rpool/data
NAME PROPERTY VALUE SOURCE
rpool/data refreservation 20G local
Qué significa la salida: Reservaste 20G para que el pool no llegue tan fácilmente a “0 bytes free” con el crecimiento de snapshots.
Decisión: En pools pequeños, una reserva es un seguro barato. En pools grandes, puede que prefieras monitorización + cuotas estrictas.
Mini-historia corporativa: optimización que salió mal
Un equipo quiso “ahorrar espacio” en un clúster Proxmox. Activaron dedup en ZFS porque en una presentación parecía dinero gratis. También activaron compresiones agresivas y dejaron todo en thin-provisioning porque los números se veían bonitos.
Durante una semana fue bien. Luego la carga cambió: más VMs de bases de datos, más churn, más snapshots. El uso de CPU en los hosts subió. La latencia se volvió irregular. Soporte lo llamó “lentitud aleatoria”, la categoría más frustrante.
Causa raíz: dedup en ZFS consume memoria y castiga cuando está justo de RAM. El DDT no cabía en RAM, así que lecturas/escrituras arrastraron más I/O adicional. Habían optimizado por capacidad y comprado sin querer un generador de latencia.
El rollback fue doloroso porque los datos ya estaban deduplicados. Terminaron migrando discos de VM a un pool nuevo y sensato: lz4, sin dedup, espacio libre holgado y una política clara de snapshots. El ahorro de espacio era real—pero el costo fue operacional. La capacidad es una métrica. La latencia es experiencia de usuario.
9) Copias de seguridad que se restauran: PBS, horarios, retención, verificación
Proxmox facilita programar backups. También facilita pensar que tienes copias cuando tienes una carpeta llena de archivos que nadie ha restaurado jamás.
Haz esto correctamente:
- Haz backups en un sistema separado (idealmente PBS). No en el mismo pool. No en el mismo host.
- Usa retención sensata. Ni “guardar para siempre”, ni “guardar dos”.
- Verifica. Prueba la restauración. Automatiza una restauración canaria si puedes.
Tarea 23: Confirmar trabajos de respaldo actuales (o su ausencia)
cr0x@server:~$ pvesh get /cluster/backup --output-format json-pretty
[]
Qué significa la salida: No hay backups programados. Esto es el valor por defecto y también la trampa.
Decisión: Crea un trabajo hoy. Si “no estás listo”, tampoco estás listo para perder datos.
Tarea 24: Comprobar destinos de almacenamiento configurados (dónde pueden ir los backups)
cr0x@server:~$ pvesm status
Name Type Status Total Used Available %
local dir active 98.00 GiB 12.30 GiB 85.70 GiB 12.55%
local-lvm lvmthin active 300.00 GiB 70.20 GiB 229.80 GiB 23.40%
Qué significa la salida: Solo tienes almacenamiento local. Los backups aquí son mejor que nada, pero no sobrevivirían a la muerte del host.
Decisión: Añade PBS o al menos un destino NFS en otra máquina. Prefiere PBS por deduplicación y semánticas de verificación diseñadas para backups de virtualización.
Tarea 25: Validar que tu destino de backup no se llenará de inmediato
cr0x@server:~$ df -h /var/lib/vz
Filesystem Size Used Avail Use% Mounted on
rpool/ROOT/pve-1 98G 13G 86G 13% /
Qué significa la salida: Si haces backups a local, estás gastando espacio del sistema raíz. Así es como dejas brickeado un nodo con “No space left on device” durante una ventana de backup.
Decisión: No vuelques backups en el root filesystem a largo plazo. Añade almacenamiento de backup separado.
Tarea 26: Ejecutar un backup manual y leer el resultado como si importara
cr0x@server:~$ vzdump 100 --storage local --mode snapshot --compress zstd --notes-template '{{guestname}} {{vmid}}'
INFO: starting new backup job: vzdump 100 --storage local --mode snapshot --compress zstd
INFO: Backup of VM 100 started at 2025-12-28 11:22:10
INFO: status = running
INFO: VM Name: app01
INFO: include disk 'scsi0' 'local-lvm:vm-100-disk-0' 50G
INFO: backup mode: snapshot
INFO: ionice priority: 7
INFO: creating vzdump archive 'vzdump-qemu-100-2025_12_28-11_22_10.vma.zst'
INFO: Total bytes written: 9876543210 (9.1GiB, 220.0MiB/s)
INFO: backup ended at 2025-12-28 11:23:05
INFO: Backup job finished successfully
Qué significa la salida: El modo snapshot tuvo éxito, se usó compresión, y se muestra el rendimiento. “Finalizado con éxito” es necesario—pero no suficiente para la recuperabilidad.
Decisión: Prueba la restauración inmediatamente en un nuevo ID de VM o en una ubicación de pruebas. No esperes al incidente.
Tarea 27: Validar que el archivo de backup existe y tiene tamaño razonable
cr0x@server:~$ ls -lh /var/lib/vz/dump | tail -n 3
-rw-r--r-- 1 root root 9.2G Dec 28 11:23 vzdump-qemu-100-2025_12_28-11_22_10.vma.zst
-rw-r--r-- 1 root root 637 Dec 28 11:23 vzdump-qemu-100-2025_12_28-11_22_10.log
Qué significa la salida: Existe el archivo de archivo y el log. Si tu “backup” pesa unos megabytes para una VM grande, probablemente respaldaste lo incorrecto o hubo un error.
Decisión: Lee el log en busca de advertencias y confirma que los discos fueron incluidos.
Tarea 28: Probar la restauración (la parte que todos omiten)
cr0x@server:~$ qmrestore /var/lib/vz/dump/vzdump-qemu-100-2025_12_28-11_22_10.vma.zst 900 --storage local-lvm
restore vma archive: zstd -q -d -c /var/lib/vz/dump/vzdump-qemu-100-2025_12_28-11_22_10.vma.zst | vma extract -v -r /var/tmp/vzdumptmp1234 - /var/tmp/vzdumptmp1234
progress 1% (reading archive)
progress 55% (reading archive)
progress 100% (reading archive)
restore successful
Qué significa la salida: La tubería de restauración se ejecutó y completó. Esa es tu señal real.
Decisión: Arranca la VM restaurada en una red aislada, verifica la salud de la aplicación y luego elimínala. Repite regularmente.
Dato interesante: La frase “ventana de backup” viene de cuando había que parar todo para volcar a cinta. Tus SSD no recibieron el memo, pero tus usuarios aún sufren si saturas el I/O de almacenamiento.
10) Registros, alertas y señales de capacidad
Un nodo Proxmox puede estar “saludable” hasta que deja de estarlo. Quieres señales tempranas: uso de disco, salud de pools, advertencias SMART, fallos de backup y reinicios inesperados.
Tarea 29: Revisar el journal en busca de errores que importen
cr0x@server:~$ journalctl -p warning -b --no-pager | tail -n 20
Dec 28 09:12:44 server kernel: nvme nvme0: I/O 123 QID 4 timeout, aborting
Dec 28 09:12:45 server kernel: ata1.00: failed command: READ DMA EXT
Dec 28 09:12:45 server kernel: blk_update_request: I/O error, dev sda, sector 1234567 op 0x0:(READ)
Qué significa la salida: Esto no es “ruido.” Timeouts y errores de I/O son advertencias de hardware o cableado, a menudo días antes de una falla.
Decisión: Si ves errores de I/O en almacenamiento, deja de optimizar y empieza a reemplazar. Ejecuta SMART, revisa cables/backplane y planifica migración.
Tarea 30: Comprobar salud SMART rápidamente (si usas SATA/SAS)
cr0x@server:~$ smartctl -H /dev/sda
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.8.12-4-pve] (local build)
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
Qué significa la salida: “PASSED” no es “como nuevo.” Solo significa que la unidad no se ha declarado muerta todavía.
Decisión: Mira sectores reasignados, sectores pendientes y logs de errores, no solo el titular.
Tarea 31: Ver uso de disco de VMs y riesgo de thin-provisioning
cr0x@server:~$ lvs -o lv_name,vg_name,lv_size,data_percent,metadata_percent,lv_attr
lv_name vg_name lv_size data_percent metadata_percent lv_attr
data pve 300.00g 78.12 4.55 twi-aotz--
Qué significa la salida: Tu thin pool está 78% lleno. Los thin pools fallan muy mal al llegar al 100%: las VMs pueden quedar en solo lectura o colapsar según la carga.
Decisión: Añade espacio o reduce asignaciones antes del 90%. También monitorea el uso de metadata; que metadata se llene es un desastre especial.
Broma breve #2: Un thin pool al 99% es el almacenamiento de Schrödinger: está bien y en llamas hasta que escribes un bloque más.
Mini-historia corporativa: práctica aburrida pero correcta que salvó el día
Una organización financiera ejecutaba Proxmox para apps internas. Nada glamoroso: un par de bases de datos, servicios de archivos y algunas VMs que todos fingían que eran “temporales” desde hace tres años.
El responsable SRE insistía en una rutina tediosa: actualizaciones semanales de host, backups nocturnos a PBS y una prueba mensual de restauración de una VM elegida al azar en una red aislada. A nadie le gustaba. Era papeleo con pasos extras.
En un cierre trimestral, un controlador de almacenamiento empezó a devolver errores intermitentes. El pool ZFS se mantuvo en línea, luego empezó a mostrar errores de checksum. El rendimiento se hundió. El incidente commander tomó la única decisión sensata: dejar de intentar ser listo y recuperarse restaurando VMs críticas en un nodo de reserva con almacenamiento limpio.
La restauración funcionó porque se había probado. Las credenciales estaban documentadas. El datastore PBS había sido verificado. El equipo no tuvo que aprender el proceso de restauración con el negocio mirando.
Después, nadie presumió de heroísmos. Ese era el punto. El trabajo de fiabilidad más valioso es el que parece aburrido en un informe de estado.
Guía rápida de diagnóstico: qué comprobar primero/segundo/tercero
Cuando Proxmox “se siente lento”, la gente culpa al hipervisor. Normalmente es una de tres cosas: latencia de almacenamiento, diseño de red malo o presión de memoria. Aquí tienes cómo encontrar el cuello de botella rápido, sin adivinar.
Primero: ¿está el host en distress ahora mismo?
cr0x@server:~$ uptime
11:41:02 up 3 days, 2:17, 2 users, load average: 8.21, 7.95, 7.10
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 64Gi 56Gi 1.2Gi 1.1Gi 6.8Gi 4.0Gi
Swap: 8.0Gi 6.5Gi 1.5Gi
Cómo interpretar: Alta carga con poca memoria disponible y mucho swap sugiere presión de memoria. La carga sola es ambigua; el swap no lo es.
Decisión: Si el swap está activo y creciendo, reduce el overcommit de memoria, añade RAM o mueve cargas. También revisa ballooning y caches del host.
Segundo: ¿es la latencia de almacenamiento la verdadera villana?
cr0x@server:~$ iostat -x 1 3
avg-cpu: %user %nice %system %iowait %steal %idle
12.00 0.00 6.00 25.00 0.00 57.00
Device r/s w/s rkB/s wkB/s await svctm %util
sda 5.0 120.0 80.0 9000.0 35.20 2.10 98.00
Cómo interpretar: %iowait es alto y %util del disco está cerca del 100% con alto await. Eso es saturación clásica de almacenamiento.
Decisión: Encuentra la VM que más habla, reduce la concurrencia de backups/replicación, mueve discos calientes a almacenamiento más rápido o añade spindles/SSDs. No “tunes” primero los knobs del kernel.
Tercero: ¿es en realidad la red (especialmente con NFS/Ceph/PBS)?
cr0x@server:~$ ip -s link show enp3s0 | sed -n '1,8p'
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
link/ether 3c:ec:ef:12:34:56 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped missed mcast
9876543210 6543210 0 120 0 12345
TX: bytes packets errors dropped carrier collsns
8765432109 5432109 0 250 0 0 0
Cómo interpretar: Paquetes descartados (RX/TX) no son normales en redes limpias. Indican congestión, problemas de driver o MTU/colas desajustadas.
Decisión: Arregla la red antes de culpar a Ceph/NFS. Luego valida la consistencia de MTU extremo a extremo si usas jumbo frames.
Bonus: encontrar la VM vecina ruidosa rápidamente
cr0x@server:~$ pvesh get /nodes/$(hostname)/qemu --output-format json-pretty | head -n 20
[
{
"cpu": 0.85,
"mem": 4294967296,
"name": "app01",
"pid": 4321,
"status": "running",
"vmid": 100
},
{
"cpu": 3.72,
"mem": 17179869184,
"name": "db01",
"pid": 9876,
"status": "running",
"vmid": 110
}
]
Cómo interpretar: Vista rápida de VMs con uso de CPU. No es perfecta, pero sirve para triage.
Decisión: Si una VM está a tope de CPU, revisa también su I/O de disco y memoria. “Alta CPU” puede ser síntoma de bloqueos por almacenamiento causando bucles activos.
Errores comunes: síntoma → causa raíz → solución
1) Síntoma: backups “exitosos” pero la restauración falla
Causa raíz: Backups guardados en el mismo host/pool, archivo corrupto, falta de config de VM o procedimiento de restauración nunca probado.
Solución: Haz backups a PBS o almacenamiento externo, realiza una prueba de restauración mensual y guarda logs. Usa verificación en PBS y trata fallos como incidentes de producción.
2) Síntoma: congelamientos aleatorios de VMs durante la ventana de backup
Causa raíz: Saturación de almacenamiento (especialmente con HDDs), demasiados trabajos de backup concurrentes o thin pool cerca de lleno causando presión en metadata.
Solución: Reduce concurrencia, escalona horarios, pon límites de I/O para tráfico de backup, mueve backups fuera del pool primario y mantén margen de espacio libre.
3) Síntoma: la UI web de Proxmox es accesible desde donde no debería
Causa raíz: Gestión y red de invitados comparten el mismo bridge/VLAN; firewall deshabilitado o mal configurado; binding por defecto a “0.0.0.0” expuesto a una LAN más amplia.
Solución: Separa la VLAN de gestión, aplica reglas de firewall, restringe acceso por upstream (ACLs de switch) y deja de tratar la “red interna” como confiable.
4) Síntoma: el clúster se vuelve raro después de un reinicio (nodos en desacuerdo, GUI muestra errores)
Causa raíz: Deriva de tiempo, inconsistencias DNS o expectativas de quórum rotas (clúster de dos nodos sin diseño de desempate).
Solución: Arregla NTP, usa hostnames estables y DNS forward/reverse, diseña el quórum apropiadamente (número impar de votantes o un qdevice).
5) Síntoma: pool ZFS está “ONLINE” pero el rendimiento es horrible
Causa raíz: Pool demasiado lleno, churn de snapshots alto, discos lentos o desajuste de carga (bases de datos en RAIDZ de HDD con muchas escrituras sincronizadas).
Solución: Mantén el pool bajo ~80%, revisa retención de snapshots, usa mirrors para cargas IOPS-intensivas, añade SLOG solo si entiendes escrituras sincronizadas y mide latencia con iostat.
6) Síntoma: VMs pasan a solo lectura o se bloquean; logs del host muestran errores de thin pool
Causa raíz: LVM-thin pool alcanzó 100% de uso de datos o metadata.
Solución: Amplía el thin pool inmediatamente, libera espacio y evita recurrencias con monitorización y provisión conservadora.
Listas de verificación / plan paso a paso
Día 0 (la primera hora tras la instalación)
- Repos: elegir enterprise vs no-subscription; ejecutar
apt-get updatey simular actualizaciones. - Admin con nombre: crear
sre-admin@pam, otorgar rol de administrador, dejar de usarroot@pama diario. - Endurecer SSH: añadir un drop-in para deshabilitar root + contraseñas; recargar SSH y probar accesos.
- Chequeo de red: inspeccionar
/etc/network/interfaces. Si la gestión comparte el bridge de invitados, planifica la corrección ahora, no “más tarde”. - Etapas del firewall: confirmar
localnet, habilitar firewall con cuidado y asegurar acceso a 8006 y 22 desde gestión. - Sincronización horaria: confirmar que
timedatectlmuestra sincronización.
Día 1 (antes de poner algo importante)
- Decisión de almacenamiento: elegir espejo ZFS o LVM-thin intencionalmente. Evitar disco único “producción”.
- Salud del pool: revisar
zpool statusyzpool list; establecer expectativas de margen. - Destino de backup: añadir PBS o almacenamiento externo. No aceptar “backups en el nodo” como estado final.
- Primer backup + prueba de restauración: ejecutar
vzdumpyqmrestorepara demostrar recuperabilidad.
Semana 1 (hacerlo sostenible)
- Señales de monitorización: decidir qué alertas necesitas: llenado de disco, errores ZFS, advertencias SMART, fallos de backup.
- Cadencia de parches: elegir una ventana; documentar expectativas de reinicio para actualizaciones de kernel.
- Política de acceso: quién tiene acceso a consola, quién es admin, quién tiene permisos a nivel VM; eliminar credenciales compartidas.
- Runbook: escribir pasos de restauración y dónde están los backups. Cuando estés estresado, no recordarás.
Preguntas frecuentes
1) ¿Debería usar ZFS o LVM-thin para almacenamiento de VMs?
Si quieres características de integridad de datos (checksums, snapshots predecibles, herramientas de replicación sencillas), elige ZFS. Si prefieres simplicidad y entiendes la monitorización de thin-pool, LVM-thin está bien. Los principiantes suelen ir mejor con espejos ZFS que con un thin pool que olvidan monitorizar.
2) ¿Puedo guardar backups en el mismo host Proxmox?
Puedes, pero no deberías llamar eso “backup” para nada que no puedas perder. La falla del host, ransomware en el host o corrupción del pool pueden llevarse las VMs y sus backups juntos. Usa un sistema separado.
3) ¿Está bien ejecutar un Proxmox de nodo único en producción?
Sí, si aceptas el riesgo y construyes buenos backups. Muchas pequeñas empresas lo hacen. Pero sé honesto: un nodo único implica downtime durante actualizaciones y cero redundancia hardware a menos que tu almacenamiento esté espejado y tengas repuestos.
4) ¿Por qué todo el mundo dice “mantén ZFS por debajo del 80%”?
El rendimiento de ZFS y el comportamiento del asignador empeoran cuando el espacio libre se reduce, especialmente con snapshots y cargas fragmentadas como imágenes de VM. Puedes operar más lleno, pero intercambias latencia estable por orgullo de capacidad.
5) ¿Necesito Ceph?
No, no para “tengo dos nodos y buenas vibras.” Ceph brilla cuando tienes suficientes nodos, red y madurez operacional para ejecutar almacenamiento distribuido. Si solo quieres almacenamiento compartido para un clúster pequeño, evalúa opciones más simples primero.
6) ¿Cuál es la forma más segura y fácil de exponer la UI web de Proxmox?
No la expongas directamente a internet. Ponla en una red de gestión, accede vía VPN o bastión y aplica MFA donde termines el acceso remoto. Si debes publicarla, trátala como cualquier otro plano de administración y ciérrala agresivamente.
7) ¿Por qué mi backup de VM tardó una eternidad aunque mis discos son rápidos?
Los backups son una tubería: lecturas de disco de VM, compresión y escritura al destino. La CPU puede ser el cuello de botella (compresión), la red puede serlo (PBS/NFS) o el almacenamiento puede saturarse por trabajos concurrentes. Usa iostat, ss/ip -s link y métricas de CPU durante la ventana de backup.
8) ¿Cómo sé si la provisión fina es segura?
Es segura cuando la monitorizas y cuando puedes ampliarla antes de que se llene. Si no tienes alertas y sueles operar pools por encima del 85–90%, no es provisión fina: es apostar con pasos extra.
9) ¿Necesito cambiar los puertos por defecto (SSH/8006)?
Cambiar puertos no es seguridad; es una leve reducción de ruido. Los controles reales son aislamiento de red, reglas de firewall, autenticación fuerte y parches. Si cambiar puertos ayuda tu modelo de amenaza, bien—pero no lo confundas con protección.
Siguientes pasos prácticos
Proxmox es lo bastante amigable para ponerte en marcha rápido, y lo bastante honesto para exponer cada mal hábito que traes. Arregla lo básico ahora: repositorios, cuentas, SSH, firewall, separación de red, sincronización horaria, diseño de almacenamiento, margen en ZFS, backups reales y señales reales.
Luego haz lo que separa “tengo un laboratorio” de “tengo producción”: programa una prueba de restauración en tu calendario y trata una copia de seguridad fallida como un incidente real. Tus VMs son cargas de trabajo. Tu nodo Proxmox es la plataforma. Mantén la plataforma aburrida, parcheada y predecible.