Hay comandos poco glamourosos que acaban siendo los más rentables del homelab. qm list y pct list están muy arriba en esa categoría. No salen en casi ningún tutorial bonito, no sirven para presumir en una captura con lucecitas y, aun así, me han evitado más reinicios torpes que muchas herramientas más sofisticadas.
Yo los uso sobre todo antes de tocar un nodo. Da igual si voy a actualizar, reiniciar, revisar almacenamiento o simplemente quitarme una duda. Antes quiero saber qué máquinas virtuales y qué contenedores viven ahí en ese momento. No lo que creo recordar, no lo que imaginé ayer, no lo que “seguro que ya estaba apagado”. Lo que está de verdad.
En homelab la memoria nos traiciona bastante. Un día arrancas una VM para probar algo y la dejas viva. Otro día levantas un contenedor porque te hacía falta un servicio puntual y te olvidas de él. Dos semanas después te plantas delante de un nodo, decides que hoy toca mantenimiento y descubres demasiado tarde que ahí seguía corriendo justo lo que no querías tocar.
Mi vacuna contra eso es bastante simple. qm list. pct list. Y luego decidir con la foto fresca delante.
por qué me importan tanto dos comandos tan básicos#
Porque Proxmox, por bueno que sea, no adivina intención. Si un nodo aloja carga real, la aloja igual aunque tú ya no lo tengas presente. Y un mantenimiento mal planteado suele empezar con una frase muy parecida a esta.
“No creo que aquí siga corriendo nada importante”.
Esa frase, en mi experiencia, es peligrosísima.
Yo prefiero sustituirla por una comprobación de diez segundos. Si luego el nodo está casi vacío, perfecto. Si no lo está, mejor enterarme antes de que el reinicio lo confirme por mí.
qué me da qm list y qué me da pct list#
qm list me enseña las máquinas virtuales del nodo. VMID, nombre, estado, memoria asignada, tamaño del disco de arranque y PID si están arrancadas.
pct list hace lo mismo con los contenedores LXC. En muchos homelabs eso es incluso más útil, porque acabas teniendo bastante más cacharrería ligera en LXC que en VM completa.
La combinación de los dos comandos me da una respuesta operativa muy clara.
- qué corre ahora mismo en este host
- qué está parado pero sigue definido aquí
- si hay locks o estados raros
- cuánta carga real me voy a llevar por delante si reinicio sin pensar
Eso no reemplaza al resto del contexto del cluster, claro. Pero sí me resuelve la pregunta local más importante. ¿Qué demonios vive aquí hoy?
una captura real que ilustra bien el problema#
Esta salida está saneada, pero viene de una comprobación real de un nodo del cluster.
A mí esta foto me sirve por varias razones.
Lo primero es lo obvio. Hay VMs corriendo. Varias. También hay bastantes contenedores activos y un buen puñado de otros parados. Solo con eso ya se cae la fantasía de “reinicio rápido y listo”.
Lo segundo es más fino. Aparece un contenedor stopped con Lock en mounted. Ese tipo de detalle me interesa mucho porque me recuerda que no todo lo que está parado es irrelevante. A veces una pieza parada sigue teniendo contexto operativo. Si paso por alto esas pistas, puedo interpretar mal el estado del nodo.
Lo tercero es que el inventario local te enseña densidad real. Un nodo puede parecer bastante tranquilo desde lejos y luego alojar justo los servicios que no querías tocar a esa hora.
lo que miro yo cuando leo esta salida#
No leo qm list y pct list como quien pasa lista sin más. Voy con preguntas bastante concretas.
1. qué está arrancado ahora mismo#
Es la primera lectura y la más importante. Todo lo que sale running me obliga a decidir si se queda, se migra o se asume la interrupción.
Esto parece básico, pero es donde más autoengaño cabe. A veces recordamos que un servicio suele vivir en otro nodo y damos por hecho que sigue allí. Luego miras la salida real y no, hoy estaba en este. Fin de la teoría.
2. qué está parado pero merece contexto#
No todo lo parado da igual. Una VM parada puede ser una plantilla o una máquina olvidada. También puede ser algo que no corre ahora, pero que sigue teniendo discos locales, snapshots o dependencias que te interesa no tocar a lo bruto.
Con LXC me fijo todavía más. Si aparece un lock, un estado raro o algo como mounted, no hago como si fuera decoración. Me paro a pensar por qué está así.
3. qué peso tiene de verdad este nodo#
A veces el número de servicios activos ya te dice si hoy ese nodo es candidato razonable a mantenimiento. Si veo una VM suelta y dos contenedores secundarios, el tono es uno. Si veo varias VMs importantes y media docena de LXC vivos, el tono cambia bastante.
Esto conecta con otro post que publiqué hace poco, Cómo reparto las VMs en mi cluster Proxmox para no convertir un nodo en el pringado de la casa. Repartir bien ayuda, pero la comprobación final siempre la hago contra la realidad del momento, no contra el plan ideal que tenía en la cabeza.
el error clásico que evito con esto#
El error clásico es muy de casa. Quieres hacer un cambio pequeño y no te apetece abrir veinte pestañas. Te acuerdas a medias de cómo estaba repartida la carga, ves que el cluster está sano y piensas que no hace falta más contexto.
Luego reinicias el nodo y pasan una o varias de estas cosas.
- cae una VM que sí importaba
- un contenedor que dabas por irrelevante estaba haciendo algo útil
- te toca migrar después, con más prisa y peor humor
- descubres un lock o un estado raro cuando ya has empezado a tocar
Yo prefiero gastar diez segundos antes y no quince minutos después preguntándome por qué no miré algo tan obvio.
por qué esta vista local me importa incluso aunque use HA#
Tener HA ayuda, sí. Pero no convierte cualquier reinicio en una buena idea.
Por eso suelo combinar inventario local con ha-manager status. Esta es otra captura saneada de una comprobación real.
Lo que hago es cruzar ambas fotos.
La salida de qm list y pct list me enseña qué vive en el nodo. La de HA me enseña qué recursos están realmente bajo gestión de alta disponibilidad y en qué host se encuentran. Cuando las dos historias encajan, puedo decidir con bastante más criterio.
Esto es importante por una razón muy simple. No todo lo que corre en un nodo está protegido por HA. Y no todo lo protegido por HA me interesa dejarlo resolver solo si puedo preparar antes una migración más limpia.
Mi postura aquí es poco heroica. Si puedo vaciar un nodo con orden, prefiero vaciarlo con orden. Dejar que el failover te salve no siempre es la opción más fina, aunque funcione.
cómo decido si un nodo está listo para reinicio o no#
No tengo una fórmula mágica. Tengo un criterio bastante casero, que al final me funciona mejor que cualquier liturgia rígida.
si solo veo carga secundaria#
Si qm list y pct list me enseñan poca actividad o servicios que no me preocupan especialmente, entonces el nodo es candidato razonable para tocarlo en ese momento.
si veo mezcla de servicios importantes y cacharreo#
Entonces ya no actúo por intuición. Miro qué debería migrarse, qué puede esperar y qué no quiero interrumpir. A veces la respuesta es mover dos cosas y seguir. Otras veces es dejarlo para una ventana un poco más limpia.
si aparece algo raro en locks o estados#
Aquí paro antes. Un inventario con una anomalía ya no es solo inventario. Es señal de que hay otra historia detrás.
el detalle de los locks me ha ahorrado sustos varias veces#
La columna Lock suele pasar desapercibida hasta que te hace falta. Error. Yo me fijo mucho.
Un recurso stopped no siempre está completamente libre de contexto. Si aparece mounted, por ejemplo, ya sé que no estoy mirando un apagado simple y limpio. Hay algo más pasando o algo quedó a medias en otro momento.
No siempre significa problema serio, pero sí significa que no quiero continuar como si nada. Lo peor que puedes hacer con un lock raro es ignorarlo porque hoy no te apetece investigarlo. Esa deuda técnica suele reaparecer justo cuando el nodo ya está a medio reinicio o cuando intentas una operación que presupone un estado más limpio del real.
esto también me ayuda a documentar mejor el homelab#
Otra cosa curiosa de mirar estos comandos con frecuencia es que te obligan a tener más claro qué corre dónde. Si cada vez que haces mantenimiento ves inventarios caóticos o servicios repartidos sin lógica, el problema no es el mantenimiento. El problema es el orden de tu lab.
A mí me pasa bastante. Hay semanas en las que todo está razonablemente limpio y qm list o pct list cuentan una historia muy entendible. Y hay otras en las que el comando funciona como espejo incómodo. Ahí ves enseguida si te has pasado un poco abriendo frentes.
Eso no me parece malo. Me parece útil. Un inventario feo te da información sobre el estado operativo real del lab, no solo sobre el nodo concreto.
lo que no hago ya nunca#
no reinicio basándome en memoria#
La memoria es comodísima hasta que falla. Para esto prefiero siempre una salida fresca.
no doy por irrelevante todo lo que está parado#
Un recurso parado puede seguir mereciendo atención, sobre todo si tiene locks o contexto raro.
no trato HA como permiso para tocar sin mirar#
HA ayuda a recuperarse. No sustituye preparación.
no mezclo inventario con suposiciones#
Si el comando y mi recuerdo discrepan, gana el comando. Siempre.
dónde encaja esto con el resto del flujo Proxmox#
Para mí estos dos comandos viven justo en medio del mantenimiento sensato.
Primero miro salud de cluster con pvecm status. Lo conté en Cómo reviso la salud de un cluster Proxmox en dos minutos antes de tocar nada. Luego miro inventario local con qm list y pct list. Y si además voy a actualizar paquetes, completo la foto con el preflight de versiones, upgrades pendientes y estado de HA.
Es decir, el inventario local no es una curiosidad. Es una pieza de contexto. Sin ella, el resto del checklist queda cojo.
una checklist mínima que me funciona#
Si voy a reiniciar o poner un nodo en mantenimiento, normalmente hago esto.
pvecm statusha-manager statusqm listpct list- decidir qué migro, qué dejo y qué pospongo
No tiene más misterio. Y justo por eso funciona. Es rápido, repetible y me obliga a trabajar con la foto real del nodo.
mi conclusión#
qm list y pct list no son comandos vistosos, pero sí de los más rentables que tengo en Proxmox. Me dicen qué vive en un nodo ahora mismo y me ahorran ese tipo de error tan tonto como común, tocar mantenimiento creyendo que el host estaba más libre de lo que estaba.
A mí me compensa revisarlos siempre. Porque la diferencia entre un reinicio tranquilo y un reinicio torpe muchas veces no la marca una gran arquitectura. La marca haber mirado o no haber mirado dos comandos muy simples en el minuto adecuado.
Y en homelab, sinceramente, prefiero parecer un poco obsesivo a parecer sorprendido cinco minutos después.
referencias#
- QEMU KVM en Proxmox VE
- Linux Containers en Proxmox VE
- High Availability en Proxmox VE
- Post relacionado: Cómo reviso la salud de un cluster Proxmox en dos minutos antes de tocar nada
- Post relacionado: Cómo reparto las VMs en mi cluster Proxmox para no convertir un nodo en el pringado de la casa
- Post relacionado: Actualizar Proxmox sin ir a ciegas: el preflight real que hago antes de un apt full-upgrade