Hay comandos que no arreglan nada, pero te ahorran media hora de estupideces.
Este es uno de ellos.
| |
Cuando Proxmox empieza con comportamientos grises, yo no siempre salto primero a la web ni a pvecm status. Muchas veces hago esta comprobación antes que nada porque me responde una pregunta muy básica.
/etc/pve sigue siendo el filesystem del cluster o ya estoy mirando otra cosa con cara de carpeta normal.
Suena pequeño. No lo es.
En Proxmox, /etc/pve no es un directorio cualquiera del sistema. Detrás está pmxcfs, el Proxmox Cluster File System. La propia documentación de Proxmox lo describe como un filesystem distribuido que replica la configuración del cluster entre nodos a través de Corosync. Si esa pieza se tuerce, empiezan a aparecer síntomas raros en cadena. Configuraciones que no cuadran. Cambios que no se guardan como esperabas. Sensación de que la web sigue ahí, pero el suelo ya no está del todo firme.
Por eso me gusta tanto este comando. Es barato, es rápido y me obliga a comprobar si el terreno sigue siendo el que creo que es.
la captura real que yo querría ver primero#
Esta salida sale de un nodo real de mi laboratorio, saneada porque mis nombres internos no aportan nada aquí.
No tiene glamour ninguno. Mejor.
La primera línea ya dice casi todo lo que me importa.
/dev/fuse on /etc/pve type fuse (rw,...)
Con eso ya sé que /etc/pve está montado como filesystem FUSE y no como una simple carpeta local perdida en el disco del nodo. En otras palabras, pmxcfs está puesto en su sitio.
Luego miro el df -h /etc/pve solo para recordar otro detalle que confunde mucho a quien llega nuevo a Proxmox. Ese tamaño de 128M no es el espacio donde viven tus discos virtuales, tus backups o tus contenedores. Es el tamaño lógico que presenta ese filesystem de configuración. Nada más.
Si intentas leer esa cifra como almacenamiento real, te vas a contar una película bastante mala.
por qué este comando me gusta más de lo que debería#
Porque responde a una pregunta previa a casi todas las demás.
Antes de interpretar quorum. Antes de obsesionarme con la web. Antes de pelearme con un storage que responde raro. Antes de tocar archivos dentro de /etc/pve como si no pasara nada.
Quiero saber si ese path sigue siendo lo que debe ser.
Si la respuesta es sí, perfecto. Ya puedo seguir con otros comandos con cierta tranquilidad.
Si la respuesta es no, el diagnóstico cambia bastante.
Y aquí hay un punto importante. No uso mount | grep "on /etc/pve " para cerrar una incidencia. Lo uso para no empezar la incidencia por el sitio equivocado.
Eso, en homelab, vale oro.
qué significa de verdad ver type fuse#
La palabra importante de esa salida no es solo /etc/pve. Tampoco /dev/fuse.
La palabra importante es fuse.
Eso me recuerda que no estoy delante de un directorio ordinario del root filesystem. Estoy delante de un filesystem en espacio de usuario que Proxmox monta para exponer la configuración compartida del cluster.
Dicho de forma menos seca, lo que hay bajo /etc/pve no vive ahí como viviría un archivo cualquiera en /etc.
Eso explica muchas cosas raras que, si no entiendes esta base, parecen magia negra barata.
Por ejemplo:
- que la misma configuración aparezca en varios nodos
- que ciertos cambios dependan del estado real del cluster
- que perder quorum no sea un detalle cosmético
- que editar a ciegas dentro de
/etc/pvecuando algo ya huele raro sea una forma bastante elegante de empeorar el día
Cuando veo type fuse, yo respiro un poco. No porque todo esté resuelto, sino porque la pieza sigue montada como debería.
por qué /dev/fuse aquí es una buena noticia#
A alguien que venga de Linux generalista esto le puede sonar raro. Ver /dev/fuse no suele sonar a tranquilidad automática.
En Proxmox, para esta comprobación concreta, sí me tranquiliza.
Me dice que la capa FUSE está activa y que /etc/pve cuelga de ahí. Justo lo que quiero confirmar antes de interpretar nada más.
Si en vez de eso no sale nada, o sale una montura que no tiene sentido para /etc/pve, ya no estoy en modo revisión cómoda. Estoy en modo “alto, primero confirmemos qué demonios está pasando aquí”.
Y eso cambia mucho la siguiente jugada.
el detalle del rw que no conviene pasar por alto#
Yo me fijo bastante en el rw.
No porque este comando me vaya a contar toda la historia de permisos o de quorum, que no lo hace, sino porque me sirve para detectar una incoherencia muy visible.
Si /etc/pve está montado en lectura y escritura como en la captura, estupendo. No demuestra que el cluster esté perfecto, pero al menos no me está gritando una limitación obvia desde la propia montura.
Si viera una situación distinta, ya me pondría bastante menos alegre.
Aquí conviene recordar otra cosa que Proxmox documenta bien. pmxcfs puede pasar a solo lectura cuando un nodo pierde quorum. Eso no siempre lo vas a deducir de un vistazo en la interfaz. Por eso me gusta tanto combinar esta comprobación con otras dos cuando algo no cuadra.
La pareja buena para mí suele ser esta:
systemctl status pve-cluster --no-pagerpvecm statusen Proxmox: cómo leo quorum, votes y ring ID antes de tocar un nodo
Una me dice si pmxcfs sigue levantado como servicio. La otra me dice si el nodo conserva base suficiente dentro del cluster. Esta de mount me da la confirmación rápida de que /etc/pve sigue siendo lo que debería ser.
Las tres juntas cuentan una historia mucho mejor que cualquiera de ellas por separado.
el tamaño de 128M no significa lo que muchos creen#
Este punto me parece importante porque he visto a bastante gente interpretarlo mal.
df -h /etc/pve enseña algo como esto:
| |
Y la primera lectura rápida suele ser pésima.
“¿Solo tengo 128M para la configuración del cluster?”
“¿Si esto se llena explota todo?”
“¿Por qué marca 1% si tengo un datacenter entero metido aquí?”
La respuesta corta es que esa cifra no te está hablando del storage real de tus VMs ni del tamaño de tus discos. Te está enseñando la vista lógica de ese filesystem de configuración. Es otra cosa.
A mí me sirve sobre todo para confirmar que sigo mirando el mismo objeto raro y específico que quería mirar. No para sacar conclusiones de capacidad general.
Si quiero entender almacenamiento de verdad, me voy por ejemplo a pvesm status en Proxmox: cómo leo el almacenamiento de verdad y qué señales no ignoro.
Confundir ambas capas es una forma bastante eficiente de liarse solo.
cuándo lanzo yo este comando sin pensarlo demasiado#
cuando la web sigue abriendo, pero no me fío#
Este caso es muy típico. El panel responde. No parece caído del todo. Pero algo huele raro. Un guardado tarda más de la cuenta. Una vista no cuadra. Un cambio no aparece donde debería.
Antes de inventarme un drama más sofisticado, compruebo que /etc/pve siga montado como toca.
después de reiniciar un nodo con historial raro#
No siempre pasa nada, claro. Pero si ese nodo ya venía con problemas de quorum, de pve-cluster o de sincronización, esta comprobación me da una primera pista muy buena en dos segundos.
antes de tocar archivos de configuración compartida#
Esto me parece casi una norma de higiene.
Si voy a mirar o cambiar algo dentro de /etc/pve, prefiero confirmar primero que no estoy operando sobre una base chueca.
cuando pve-cluster dice que vive, pero yo sigo con dudas#
systemctl status pve-cluster me encanta, y ya conté por qué en systemctl status pve-cluster en Proxmox: cómo compruebo pmxcfs antes de culpar a la web o a /etc/pve. Pero a veces quiero la verificación visible desde el path concreto, no solo desde systemd.
Ahí entra este comando.
lo que hago si el comando no devuelve nada#
Si mount | grep "on /etc/pve " no devuelve nada, no sigo como si tal cosa.
Ese silencio me importa mucho más que un warning vistoso en otro sitio.
Porque entonces la pregunta deja de ser “qué falla en esta configuración” y pasa a ser “está realmente montado el filesystem del cluster donde debería”.
Mi secuencia corta en ese caso suele ser esta:
systemctl status pve-cluster --no-pagerjournalctl -u pve-cluster -n 40 --no-pagerpvecm status
Si pve-cluster está caído o el journal enseña errores contra Corosync, ya sé por dónde seguir. Si además pvecm status no da quorum o enseña una vista rara del cluster, mejor todavía, porque el dibujo empieza a cerrar.
Lo que no hago es ponerme a editar archivos o a culpar al navegador mientras /etc/pve ni siquiera está claramente montado como espero.
un error bastante humano, tratar /etc/pve como si fuera un /etc cualquiera#
Esto pasa muchísimo.
Ves un path. Ves archivos. Ves directorios. El cerebro Linux hace el resto y asume que estás delante de una jerarquía local corriente.
Con Proxmox eso es una trampa muy fea.
/etc/pve parece una carpeta. Funciona como interfaz de archivos. Pero la historia de fondo es otra. Hay pmxcfs, hay Corosync, hay estado de cluster, hay reglas particulares cuando falta quorum, y hay consecuencias bastante reales si decides tocar cosas sin confirmar el contexto.
Por eso me gusta tanto empezar por una comprobación tan poco glamourosa. Me obliga a recordar que este path tiene una naturaleza distinta.
Y cuando estoy cansado, agradezco cualquier comando que me impida hacerme trampas a mí mismo.
qué me dice este comando y qué no me dice#
Sí me dice:
- que
/etc/pveestá montado o no - que la montura usa FUSE
- que la ruta sigue apuntando al tipo de filesystem que espero en Proxmox
- que merece la pena seguir investigando por capa de cluster y no solo por capa de interfaz
No me dice:
- si el quorum está sano
- si Corosync va fino
- si todos los nodos ven exactamente lo mismo
- si el problema real es storage, red o una tarea concreta
- si una operación compleja va a funcionar bien solo porque
/etc/pvesiga montado
Eso es importante. Este comando no es una sentencia final. Es una comprobación de contexto.
Pero una comprobación de contexto muy buena.
con qué lo cruzo casi siempre#
Cuando la cosa viene torcida, suelo encadenarlo con estos otros posts de la serie porque se complementan muy bien:
- systemctl status pve-cluster en Proxmox: cómo compruebo pmxcfs antes de culpar a la web o a /etc/pve
pvecm statusen Proxmox: cómo leo quorum, votes y ring ID antes de tocar un nodo- journalctl -u pve-cluster -n 40 –no-pager en Proxmox: cómo leo pmxcfs cuando Corosync se rompe y /etc/pve deja de inspirar confianza
El orden me gusta así.
Primero confirmo que /etc/pve sigue montado como filesystem del cluster.
Luego miro si pve-cluster está vivo.
Después confirmo el estado de quorum.
Y si ya huele a avería seria, me voy al journal.
Con esa secuencia me ahorro muchos rodeos tontos.
mi regla práctica con este comando#
Si /etc/pve me sale montado como FUSE y todo lo demás acompaña, sigo investigando con calma.
Si no me sale así, bajo el ritmo y dejo de asumir cosas.
No es el comando más famoso de Proxmox. Tampoco el más vistoso. Pero me parece de los más útiles para evitar diagnósticos torpes en los primeros dos minutos.
Y en un cluster, esos dos minutos deciden bastante a menudo si vas a arreglar algo o si vas a ponerte creativo donde no toca.