Antes de tocar discos en Proxmox uso qm disk rescan con dry-run, cruzo la salida con pvesm status y separo problemas de storage, discos unused y tamaños que el invitado todavía no ve.
Hay averías de Proxmox que son bastante honestas.
Fallan, te sueltan un mensaje claro y listo. No hace falta montar una tesis.
Y luego están las otras. Las que se presentan con una consola que tarda, una tarea que responde raro, un storage que a veces sale y a veces no, o una acción desde la web que no termina de cuadrar con la sensación del nodo. Ahí es donde systemctl status pvedaemon me da una foto útil, sí, pero muchas veces se me queda corto. Quiero historia reciente. Quiero saber qué ha pasado hace cinco minutos, no solo si el servicio sigue levantado.
Hay fallos en Proxmox que se ven clarísimos y hasta tienen algo de dignidad.
Se cae un servicio. Un nodo desaparece. El quorum se rompe. Perfecto. Molesta, pero al menos sabes que tienes un problema de verdad delante.
Luego están los otros.
Los que empiezan con detalles pequeños y bastante irritantes. Un storage que aparece intermitente. Una cifra que no cuadra. Un nodo que sigue vivo, pero transmite esa sensación fea de que por dentro hay algo torcido. La web aún carga. El SSH también. No parece una caída limpia. Parece más bien que alguna pieza del sistema sigue haciendo trabajo, pero lo hace arrastrando una zapatilla.
Cuando una VM va torpe y hay storage compartido de por medio, la tentación es preciosa. Todo el mundo mira a Ceph, pone cara grave y empieza a hablar de latencia como si ya supiera qué pasa. Yo intento no entrar tan rápido en esa película.
Antes de abrir la interfaz, antes de ponerme a revisar gráficas y antes de culpar al cluster entero, lanzo ceph -s.
No porque el comando me vaya a explicar toda la historia. No lo hace. Pero sí porque me da en pocos segundos una lectura muy útil del tono real del cluster. Si está limpio, si viene tocado, si hay PGs degradadas, si hay OSDs en un estado raro o si el problema ya lleva rato dejando huellas bastante visibles.
Hay comandos que no parecen gran cosa hasta que te ahorran media tarde de diagnósticos torpes. pveperf está en esa categoría.
No es bonito. No es moderno. No sirve para enseñar una captura impresionante en redes. Pero a mí me resulta muy útil porque me da en segundos una foto bastante honesta del nodo Proxmox antes de hacer dos cosas que salen caras cuando las haces mal. Actualizar confiado y culpar al cluster de algo que en realidad es culpa del host.
Una de las cosas que más me gustan de Proxmox es que te deja ver bastante verdad si preguntas bien. Una de las cosas que más me fastidian es que también te deja interpretar mal esa verdad si vas demasiado deprisa. local-lvm es un ejemplo perfecto.
Esta madrugada estuve comparando el estado de almacenamiento de tres nodos del mismo cluster. En dos de ellos, local-lvm aparecía activo, con su thin pool funcionando y varios discos locales viviendo ahí. En el tercero, la historia era otra. local-lvm salía inactivo y el sistema escupía un mensaje bastante poco ambiguo. no such logical volume pve/data.
Hay fallos que se agradecen porque son honestos. El servicio no arranca, el nodo se cae o el storage sale claramente inactivo y ya sabes que toca arreglar algo. Luego están los otros, los que te miran a la cara con media verdad. Esta madrugada me encontré justo uno de esos en Proxmox.
Tenía un storage CIFS configurado en el cluster para usarlo con ISOs, backups puntuales y algún archivo compartido. Nada exótico. Lo raro fue esto. En dos nodos el recurso seguía apareciendo montado, el mount lo enseñaba sin rubor y, si te quedabas en la superficie, podías pensar que el problema era menor. Pero en cuanto intentaba tocar ese punto de montaje con df -h, la respuesta era bastante menos diplomática. Host is down.
Hay comandos que parecen poca cosa y luego te acaban enseñando medio estado del sistema si los lees con un poco de mala leche. pvesm status es uno de esos. Mucha gente lo abre, confirma que hay varios active, ve porcentajes que no dan miedo inmediato y pasa a otra cosa. Yo ya no lo hago así.
Con los años he aprendido que el almacenamiento en Proxmox rara vez te avisa con un único dramatismo limpio. Más bien va dejando señales pequeñas. Un storage que sigue activo pero ya va demasiado lleno. Un local-lvm que aparece inactivo y no sabes si es normal o una chapuza heredada. Un backup server que aún aguanta, pero está más cerca del borde de lo que te gustaría admitir. Nada de eso suena a tragedia instantánea. Precisamente por eso conviene mirar bien.
Ceph tiene muy buena prensa en el mundo homelab. Es normal. Sobre el papel suena brillante. Almacenamiento distribuido, replicación, tolerancia a fallos, integración muy seria con Proxmox y la sensación de que estás montando algo que se parece a un entorno de verdad. El problema es que, cuando bajas del PowerPoint al salón de casa, Ceph también te recuerda muy rápido que no le importan tus ilusiones.
Yo no lo digo desde fuera. Lo tengo corriendo en un cluster pequeño de Proxmox y me gusta. De hecho, me sigue pareciendo una de las piezas más potentes que puedes montar en casa si sabes muy bien por qué la estás montando. Pero también creo que muchísima gente lo recomienda demasiado pronto, como si fuera el siguiente paso natural después de instalar tres nodos y aprender a pronunciar “quorum” sin pestañear.
Después de perder datos por un nodo caído, instalé Longhorn en mi clúster K3s. Réplicas automáticas, backups a MinIO y snapshots integrados. Esto es lo que tendrías que saber antes de que te pase lo mismo.
Llevo tres años con un Synology DS1621+ en producción. He considerado cambiarlo dos veces, y las dos veces decidí quedarme. Aquí está todo lo que aprendí sobre NAS para homelab.
