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.
Si lees eso sin contexto, es fácil sacar la conclusión equivocada. O pensar que tienes un nodo roto. O pensar que Proxmox está mintiendo. O peor, asumir que todos los nodos de un cluster deberían tener exactamente la misma realidad local porque comparten la misma configuración lógica.
Yo creo que aquí conviene separar dos ideas que la gente mezcla mucho.
La primera es que el nombre local-lvm puede ser el mismo en varios nodos. La segunda es que ese nombre no obliga a que todos esos nodos tengan idéntica estructura física ni el mismo uso del almacenamiento local. Y cuando entiendes eso, la lectura cambia bastante.
el detalle que me hizo parar#
La comparación real, saneada para no enseñar datos internos, se parece a esto.
En dos nodos la línea era la esperable.
local-lvmactivo- thin pool presente
- varios discos de VM viviendo ahí
- porcentaje de uso razonable, en torno al siete por ciento
En el tercero, nada de eso.
local-lvminactivo- capacidad total a cero
- uso a cero
- mensaje previo indicando que
pve/datano existe
No hace falta adornarlo mucho. Es una diferencia real entre nodos del mismo cluster. La pregunta útil no es “¿cómo puede ser?”. La pregunta útil es “¿esto significa una avería o una consecuencia lógica del diseño actual del nodo?”.
por qué un mismo nombre no implica la misma realidad en todos los nodos#
Aquí es donde mucha gente se tropieza. En Proxmox, la definición de storage vive a nivel de cluster, sí. Ves el mismo nombre, el mismo tipo y el mismo identificador lógico en toda la interfaz. Eso da una sensación de uniformidad muy fuerte.
Pero local-lvm no deja de ser almacenamiento local de cada nodo. No es Ceph. No es un NFS compartido. No es una piscina común de discos donde todos beben lo mismo. Cada nodo tiene que sostener ese storage con su propia realidad física.
Si un nodo tiene un NVMe principal con partición para root, swap y un thin pool data, local-lvm funcionará ahí. Si otro nodo fue montado con un reparto distinto y ese thin pool ya no existe porque el disco local se dedicó a otra cosa, el nombre puede seguir definido en la configuración y aun así no tener respaldo real.
Y eso, aunque suene obvio escrito así, se olvida muchísimo en el día a día.
lo que vi al bajar una capa#
Cuando veo una diferencia así, la tabla de pvesm status ya no me basta. Me voy a lsblk y lvs para ver la foto real del nodo.
En los dos nodos sanos para esta historia, la estructura era la típica de Proxmox instalado sobre un NVMe con LVM thin.
- partición EFI
pve-rootpve-swappve-data_tmetapve-data_tdatapve-datacomo thin pool útil para discos locales
Además, en esos nodos ya había volúmenes de VM viviendo dentro de data. O sea, no era solo una definición bonita. Era un pool real, operativo y en uso.
En el nodo raro, en cambio, la cosa era bastante distinta. Había root, había swap, había discos dedicados a OSDs de Ceph, pero no aparecía ningún pve-data ni el conjunto habitual de metadatos del thin pool local.
Eso me cambió la lectura por completo. Ya no estaba ante un bug mágico. Estaba ante un nodo cuya estructura real no incluía ese thin pool, aunque el nombre local-lvm siguiera existiendo en la configuración compartida.
la captura que más valor me dio#
La salida saneada de lsblk y lvs era más o menos esta.
A mí esta imagen me gusta más que muchas tablas bonitas porque obliga a bajar al hierro lógico del nodo.
Se ve enseguida algo importante.
- el disco de sistema sostiene
rootyswap - los NVMe grandes están absorbidos por OSDs de Ceph
- no existe el thin pool
dataque Proxmox esperaría paralocal-lvm
Con esa foto, el mensaje no such logical volume pve/data deja de ser misterioso. No es que Proxmox esté de humor raro. Es que está intentando encontrar un volumen lógico que ya no forma parte de la realidad del nodo.
cuándo esto me parece grave y cuándo me parece deuda vieja#
No todo local-lvm inactive es una emergencia. Esa es la parte que más me interesa dejar clara.
me parece grave cuando alguien espera usarlo#
Si el equipo cree que ese nodo todavía dispone de almacenamiento local para discos de VM, entonces sí hay un problema. No tanto porque el storage salga inactivo, sino porque la expectativa operativa no coincide con la realidad. En algún momento alguien intentará desplegar o mover algo ahí y se llevará un bofetón bastante tonto.
me parece grave cuando esa discrepancia es accidental#
Si el thin pool debería existir y desapareció por corrupción, fallo de disco o una cirugía de LVM hecha regular, entonces toca investigar y no precisamente con calma zen.
me parece menos grave cuando el nodo fue rediseñado a propósito#
Aquí estaba mi sospecha principal. El nodo parecía haber sido reconvertido de forma bastante consciente para usar el almacenamiento local de otra manera y dedicar el músculo real a Ceph. Si eso es así, el local-lvm inactive no es una avería activa. Es más bien una pieza vieja del mapa que nadie ha borrado del todo.
me sigue molestando aunque no sea urgente#
Esto también quiero decirlo claro. Que algo no sea una urgencia no lo convierte en bonito. A mí me molestan mucho las medias verdades en infraestructura. Un storage definido pero inexistente no rompe hoy, vale. Pero mañana puede confundir a otro, o a ti mismo dentro de tres meses.
por qué esta diferencia es bastante normal en homelab#
En entornos domésticos o pequeños acabamos montando nodos con historias distintas. Uno nació con un SSD para sistema y otro para datos. Otro fue reaprovechado. Otro lo reconstruiste un domingo con más prisa de la que admites. Otro pasó de usar discos locales a volcar casi todo en Ceph porque cambió su papel dentro del cluster.
Eso hace que la uniformidad lógica del cluster oculte una heterogeneidad física bastante real. Y esa heterogeneidad no es pecado. El error es olvidarla.
De hecho, yo diría que en homelab es más honesto asumir que los nodos son primos, no gemelos. Quieres que trabajen juntos, sí. Pero no siempre tienen el mismo cuerpo por dentro.
la trampa de pensar que local-lvm importa igual que Ceph#
Otra confusión frecuente es tratar local-lvm como si tuviera el mismo peso conceptual que un storage compartido.
No lo tiene.
Ceph, un PBS o un NFS bien montado cambian el comportamiento del cluster entero. local-lvm cambia el comportamiento de ese nodo. Punto. Que falte en un host no significa automáticamente que el cluster esté cojo. Significa que ese host ha perdido o no tiene una capacidad local concreta.
Eso puede importar mucho o poco según cómo uses el nodo.
- si ese host necesita alojar discos locales, importa bastante
- si ese host vive sobre Ceph y no esperas usar
local-lvm, importa mucho menos - si el storage sigue en la configuración pero nadie lo usa, molesta más por claridad que por riesgo inmediato
Esta diferencia me parece clave para no dramatizar de más y tampoco trivializar cuando no toca.
cómo decido si lo limpio o lo dejo quieto de momento#
Aquí no tengo una religión rígida, pero sí una preferencia clara. Si un storage local ya no existe de verdad y no va a volver, tarde o temprano prefiero limpiarlo de la configuración o al menos documentarlo muy bien.
Lo que no me gusta es el terreno intermedio de “ya sé que no está, pero lo dejo porque total”. Ese porque total es la frase favorita de la deuda técnica simpática.
Mi criterio suele ser este.
lo dejo temporalmente si estoy validando una migración o un cambio de diseño#
Si acabo de mover cargas, rehacer discos o reconvertir el nodo, no me parece mal observar un poco antes de tocar más cosas.
lo limpio si ya sé que no volverá#
Si el nodo no va a tener thin pool local otra vez, me parece mejor dejar de fingir. Menos ruido, menos confusión y menos posibilidades de que alguien haga una suposición mala.
no toco nada a ciegas si aún no entiendo el papel del nodo#
Esto es importante. Antes de quitar una definición de storage prefiero tener clarísimo qué depende de ella, aunque hoy parezca que no depende nada.
el detalle que más me ayudó a no sacar conclusiones torpes#
Fue ver el contraste entre nodos. En dos de ellos local-lvm no solo estaba activo, sino que contenía discos reales de VMs. En el tercero no existía el pool. Esa comparación me recordó una cosa bastante básica y bastante fácil de olvidar.
Cuando administras un cluster, no estás administrando una abstracción. Estás administrando varios equipos concretos que comparten ciertas capas y no comparten otras.
La configuración común te ayuda mucho. La física local sigue mandando cuando hablamos de discos locales.
lo que haría si te encuentras esto mañana#
Si abres pvesm status y ves un local-lvm inactive en un solo nodo, yo haría esto.
- Mira si el mensaje menciona
pve/datao un volumen concreto ausente. - Comprueba
lsblkylvsen ese host. - Compara con otro nodo donde sí esté activo.
- Decide si ese thin pool debería existir o si la arquitectura actual ya no lo necesita.
- Si ya no lo necesita, documenta o limpia. Si debería existir, investiga la causa real.
No empezaría reinstalando cosas ni recreando volúmenes por impulso. Antes quiero saber si estoy viendo una rotura o una huella de un diseño anterior.
lo que no hago ya nunca#
no asumo que un nombre compartido significa un backend idéntico#
Es cómodo pensarlo. También es falso bastante a menudo.
no miro solo la UI cuando el storage me chirría#
Bajo a lsblk, lvs, vgs o pvs bastante rápido.
no dramatizo un inactive sin entender el papel real del nodo#
A veces es una avería. A veces es simplemente una definición vieja que no se ha limpiado.
no dejo demasiadas medias verdades si ya sé la respuesta#
Si un nodo no va a tener local-lvm nunca más, prefiero que el cluster deje de insinuar lo contrario.
dónde encaja esto con el resto del cluster#
Esta lectura me parece inseparable de otras tres piezas.
Primero, del post de pvesm status en Proxmox: cómo leo el almacenamiento de verdad y qué señales no ignoro, porque ahí ya contaba que una línea inactive sin contexto vale poco. Segundo, de Ceph en homelab: cuándo merece la pena y cuándo solo te roba horas, porque cuando un nodo vive más para Ceph que para discos locales, la importancia de local-lvm cambia bastante. Y tercero, de Proxmox cluster de 3 nodos en mini PCs: lo que haría distinto después de montarlo en casa, porque en clusters pequeños la heterogeneidad de hardware y decisiones pesa más de lo que parece.
También conecta con la rutina corta que uso antes de tocar nada serio en Cómo reviso la salud de un cluster Proxmox en dos minutos antes de tocar nada. Si el storage ya cuenta una historia rara, prefiero entenderla antes de hacerme el valiente.
mi conclusión#
Ver local-lvm activo en dos nodos e inactivo en un tercero no significa automáticamente que el cluster esté roto. Muchas veces significa algo más pedestre y más útil. Que el nombre lógico sigue siendo común, pero la realidad física de ese nodo ya es otra.
Para mí la clave está en no discutir solo con pvesm status. Hay que bajar una capa y mirar si existe de verdad pve/data, si hay thin pool, si hay discos viviendo ahí y si el papel del nodo sigue justificando ese storage local.
En este caso, la comparación me sirvió para no sacar una conclusión torpe. No vi magia negra. Vi un nodo con una estructura distinta, probablemente orientado a otra función, y una definición compartida que ya no encaja del todo con esa realidad.
No es dramático. Pero tampoco es precioso. Y en homelab muchas veces la diferencia entre una cosa y otra ya te dice bastante sobre lo que toca hacer después.
referencias#
- LVM Thin en Proxmox VE
- Storage en Proxmox VE
- Logical Volume Manager Administration
- Post relacionado: pvesm status en Proxmox: cómo leo el almacenamiento de verdad y qué señales no ignoro
- Post relacionado: Ceph en homelab: cuándo merece la pena y cuándo solo te roba horas
- Post relacionado: Proxmox cluster de 3 nodos en mini PCs: lo que haría distinto después de montarlo en casa