- Nunca trates /etc/pve como un directorio normal
- Nunca elimines discos VM directamente del almacenamiento
- Nunca ejecutes zpool destroy sin verificar dependencias
- Nunca destruyas volúmenes LVM-thin manualmente
- Nunca rediseñe el networking de Corosync casualmente
- Nunca ejecute un cluster de dos nodos sin entender el quórum
- Nunca instale Docker y software de infraestructura aleatorio en el hipervisor
- Nunca cambie el rede de Proxmox de forma remota sin acceso out-of-band
Descubre los 8 errores más comunes al usar Proxmox y cómo evitarlos para mantener tu homelab funcional y libre de problemas. ¡Optimiza tu experiencia al máximo!
Proxmox brilla cuando lo usas tal como fue concebido. Crear un homelab funcional puede ser cuestión de horas, pero esa misma simplicidad puede llevar a errores comunes.
Para manejar un host de Proxmox de forma efectiva, debes conocer qué elementos pertenecen al propio Proxmox y cuáles son parte del almacenamiento, la red y el sistema operativo. A continuación, se describen 8 errores que surgen al cruzar esos límites sin entender lo que ocurre en el fondo.
Nunca trates /etc/pve como un directorio normal
Proxmox utiliza su propio sistema de archivos para la configuración del clúster
Los administradores acostumbrados a archivos de configuración de Linux pueden malinterpretar /etc/pve. A simple vista, parece un directorio más dentro de /etc, pero en realidad, Proxmox emplea el Proxmox Cluster File System (pmxcfs) para gestionar esta configuración.
Aquí se almacena información crucial: máquinas virtuales, contenedores, configuración del clúster, control de acceso, certificados y mucho más. En un clúster, pmxcfs permite que esta configuración esté disponible entre los nodos.
Por lo tanto, las operaciones comunes en este sistema de archivos exigen precaución. Eliminar archivos porque parecen obsoletos o reemplazar configuraciones sin más puede generar problemas que van más allá de una simple desconfiguración en Linux.
Utiliza las herramientas de gestión de Proxmox al modificar los recursos. Si necesitas hacer cambios directos, asegúrate de comprender cómo pmxcfs maneja los archivos implicados y el impacto de esos cambios en el clúster.
Nunca elimines discos VM directamente del almacenamiento
Proxmox necesita saber lo que sucedió con un disco virtual
Un disco virtual tiene su representación en Proxmox y también un objeto en el almacenamiento subyacente. Dependiendo de tu configuración, ese objeto puede ser un archivo, un volumen LVM-thin, ZFS o una imagen Ceph RBD.
Eliminar manualmente el objeto puede dejar a la VM referenciando algo que ya no existe. No notarás el problema de inmediato si la VM está apagada, lo que puede hacer que eliminarlo manualmente parezca tentador. Sin embargo, los fallos se hacen evidentes al iniciar la VM o al modificar su configuración.
Este mismo riesgo aplica a discos que parecen pertenecientes a VMs eliminadas. Antes de eliminar, verifica la configuración de Proxmox y el inventario de almacenamiento. Para eliminar discos VM, usa la GUI de Proxmox o qm, asegurando que la virtualización y el almacenamiento permanezcan sincronizados.
Nunca ejecutes zpool destroy sin verificar dependencias
ZFS realizará operaciones destructivas fielmente
ZFS ofrece a los administradores de Proxmox capacidades de almacenamiento poderosas, pero añade complejidad al emplear comandos destructivos sin una revisión previa.
zpool destroy es especialmente peligroso; eliminar un pool elimina el almacenamiento subyacente de todos los conjuntos de datos y zvols dentro de él. Si ese pool proporciona almacenamiento a Proxmox, las repercusiones pueden afectar directamente a máquinas virtuales y contenedores.
Antes de realizar esta acción, examina el pool.
Examina el uso de herramientas ZFS y su implementación en Proxmox. Verifica la configuración de almacenamiento, los discos de VMs, los sistemas de archivos raíz de contenedores, conjuntos de datos, zvols, snapshots, replicación y ubicaciones de copias de seguridad. Un pool que parece innecesario desde la perspectiva de ZFS podría, sin embargo, tener relevancia en el entorno de virtualización.
Nunca destruyas volúmenes LVM-thin manualmente
LVM ve volúmenes que Proxmox gestiona como discos virtuales
El almacenamiento LVM-thin es un campo minado para daños accidentales. Sus volúmenes lógicos son fácilmente accesibles desde la línea de comandos. Comandos como lvs y lvdisplay permiten inspeccionar objetos de almacenamiento, pero no revelan cómo Proxmox los utiliza en realidad.
Un volumen fino representa un disco virtual ligado a una máquina virtual (VM). Si lo eliminas directamente con LVM, dejas a Proxmox en una configuración inconsistente, referenciando un volumen ausente. La situación inversa también puede ser problemática: objetos de almacenamiento antiguos pueden quedar tras eliminar recursos.
Deja que Proxmox maneje las operaciones de ciclo de vida de las VMs. Ambos, la GUI y qm, comprenden que el disco virtual forma parte de una configuración más amplia y pueden actualizar el estado adecuadamente.
Nunca rediseñe el networking de Corosync casualmente
La comunicación del cluster merece una planificación del rede deliberada
Corosync es clave para la comunicación entre nodos del cluster de Proxmox, incluyendo la membresía y el quórum. Su red es crucial, mucho más que una simple conexión de servicio.
Un cluster puede parecer saludable mientras la red de Corosync esté operando bien. Pero tras un cambio de switch, una nueva interfaz, un ajuste en el enrutamiento o una reconfiguración de VLAN, pueden surgir problemas.
Un camino de Corosync poco fiable puede hacer que los nodos desaparezcan, afectar el quórum y entorpecer las migraciones. Aunque parezcan problemas de Proxmox, en realidad se originan en la capa de comunicación. Planifica el networking de Corosync como infraestructura y considera escenarios de latencia y fallos antes de realizar cambios.
Nunca ejecute un cluster de dos nodos sin entender el quórum
Dos nodos crean un escenario de fallo incómodo
Los clusters de dos nodos son atractivos para homelabs: es más fácil manejar dos servidores que tres. El problema es que un sistema distribuido requiere un método confiable para determinar los miembros del cluster ante una falla en la comunicación.
Imagina dos nodos de Proxmox que pierden comunicación. Uno podría estar bloqueándose, mientras el otro sigue operativo. O ambas máquinas funcionan normalmente, pero un switch o enlace de red falla. Desde la perspectiva de cada nodo, las situaciones son difíciles de diferenciar.
El quórum existe para evitar que ambos nodos actúen independientemente, haciendo que un nodo sobreviviente se restrinja al perder contacto. Un QDevice puede otorgar un voto extra en configuraciones de dos nodos, proporcionando una forma de alcanzar la mayoría.
Nunca instale Docker y software de infraestructura aleatorio en el hipervisor
El host de Proxmox debe permanecer enfocado en la infraestructura
Instalar otro servicio en el host de Proxmox puede parecer atractivo: un agente de monitoreo, un contenedor de Docker o incluso un servicio web ligero. Pero, poco a poco, se acumula software que altera el networking, modifica reglas del firewall y afecta el almacenamiento. Cada nueva carga de trabajo suma complejidad y riesgos a la plataforma que debe gestionar tus cargas efectivas.
Docker es un clásico en homelabs. Los administradores, bien saben lo práctico que resulta. Al ejecutar aplicaciones en una VM o un contenedor diseñado, mantienes esas cargas separadas de las operaciones del hipervisor. Ello simplifica el mantenimiento del sistema en su conjunto.
Nunca cambie el rede de Proxmox de forma remota sin acceso out-of-band
Un error de rede puede eliminar el único camino que tiene para arreglarlo
Proxmox ofrece gran flexibilidad en networking. Con puentes de Linux, puentes VLAN y múltiples interfaces físicas, construir redes virtuales se vuelve viable sin necesidad de hardware adicional. Pero un error en la configuración —una interfaz mal nombrada, una puerta de enlace incorrecta— puede dejar el host inalcanzable tras un reinicio del servicio de red. Si estás al lado de la máquina, puedes solucionarlo, pero si estás a distancia y solo tienes acceso por SSH o la interfaz web, la recuperación se complica.
Antes de ejecutar cambios significativos en el networking de forma remota, asegúrate de contar con otra vía de gestión. IPMI, una consola serial o algún mecanismo de acceso fuera de banda pueden salvarte cuando la red falla.
La mentalidad más segura de Proxmox es respetar las capas
Los errores graves en Proxmox no suelen provienen de comandos oscuros. Generalmente, surgen de acciones que parecen sensatas, enfocándose en una sola capa del sistema. Proxmox te brinda poderosas herramientas para gestionar esta complejidad. Los mejores resultados llegan cuando se utilizan esas herramientas, entendiendo los sistemas que las sostienen, en lugar de saltarse pasos porque un comando de Linux parece más sencillo.
Si deseas encontrar artículos similares a 8 cosas que nunca deberías hacer en Proxmox (a menos que quieras que tu homelab se bloquee), te sugerimos revisar la categoría Tutoriales.
Deja una respuesta