qm pending es el comando que miro cuando no quiero discutir con un fantasma.
En Proxmox puedes cambiar algunos parámetros de una VM y que el cambio no se aplique inmediatamente. Memoria, CPU, ciertas opciones de hardware, algún ajuste que necesita reinicio. La interfaz suele avisarlo, pero si estás trabajando por terminal o saltando entre nodos, es muy fácil perder ese detalle.
Y entonces empieza la comedia.
Crees que una VM tiene 6 GB de RAM porque acabas de configurarlo. Dentro sigue comportándose como si tuviera 4 GB. Miras la aplicación. Miras el sistema invitado. Miras gráficas. Te preguntas si Proxmox se ha quedado tonto. Media hora después descubres que el cambio estaba pendiente y la VM nunca reinició.
No es un fallo espectacular. Es peor. Es un fallo tonto, de los que molestan porque sabes que podías haberlo evitado con una comprobación de cinco segundos.
Ahí entra qm pending.
| |
Si no hay nada pendiente, respiras. Si hay cambios, los ves antes de tomar decisiones con una realidad que todavía no existe.
la captura de este post#
La imagen está montada a partir de una salida real y saneada de mi laboratorio. El ejemplo enseña justo el caso típico. Cambio memoria, Proxmox acepta la nueva configuración, pero la VM aún sigue con la memoria activa anterior hasta que se reinicia.
No es una captura vistosa. Tampoco necesita serlo. Lo útil está en esa línea pequeña.
| |
Eso me dice que la configuración actual efectiva y la configuración deseada no coinciden todavía. Y esa diferencia cambia cómo interpreto todo lo demás.
qué significa que haya cambios pendientes#
En Proxmox, una VM tiene una configuración. Parte de esa configuración se puede modificar en caliente. Otra parte requiere reinicio o parada de la máquina. Cuando haces un cambio que no puede aplicarse al instante, Proxmox lo deja pendiente.
qm pending te enseña esa diferencia.
No es una lista de deseos. No es un log histórico. No es una auditoría completa de cambios. Es mucho más concreto. Te dice qué valores están esperando a aplicarse.
A mí me gusta leerlo así.
- valor actual
- valor nuevo
- decisión pendiente
Si veo memory: 4096 -> 6144, no pienso “esta VM tiene 6 GB”. Pienso “esta VM sigue con 4 GB hasta que aplique el cambio”.
Ese matiz importa muchísimo.
por qué me parece tan útil#
Porque evita un tipo de error muy común en homelab. Confundir configuración guardada con estado real.
La interfaz te deja cambiar algo. El comando devuelve éxito. Mentalmente das el cambio por hecho. Pero la VM viva sigue corriendo con lo anterior.
En servidores profesionales esto se documenta, se planifica y se revisa con procedimientos. En casa, muchas veces hacemos cambios a ratos. Cinco minutos antes de cenar. Una noche después de acostar a la niña. Entre dos tareas. No siempre hay una ventana formal ni una checklist preciosa.
Por eso me gustan los comandos que reducen ambigüedad.
qm pending no te hace más listo. Te hace menos confiado, que a veces es justo lo que hace falta.
el caso clásico: memoria#
La memoria es el ejemplo más fácil de entender.
Tienes una VM con 4 GB.
| |
Ves esto.
| |
Decides subirla a 6 GB.
| |
Proxmox acepta el cambio. Si la VM está encendida y el cambio no se aplica como esperas en ese contexto, puedes acabar con una diferencia pendiente.
| |
Y aparece.
| |
Esa línea vale oro cuando estás diagnosticando rendimiento. Si dentro de la VM ves 4 GB, no hay misterio. No está ignorando tu voluntad. El cambio todavía no está activo.
Aquí es donde conviene no enfadarse con la máquina. La máquina está siendo bastante clara. El problema era no preguntarle.
CPU y cambios que parecen aplicados pero no lo están#
Con CPU pasa algo parecido. Cambias cores, sockets o modelo de CPU y das por hecho que ya está. Luego una aplicación sigue comportándose igual, una migración no sale como esperabas o el sistema invitado muestra lo anterior.
Antes de entrar en teorías raras, miro pendientes.
| |
Si aparece un cambio de CPU, ya sé que tengo una deuda. Puedo decidir cuándo reiniciar, pero al menos no sigo interpretando métricas con una configuración imaginaria.
Esto me parece especialmente importante en VMs que llevan mucho uptime. Una máquina puede acumular pequeños cambios pendientes porque nunca encontraste el momento de reiniciarla. Cada cambio individual parecía menor. Juntos forman una trampa.
Y luego un día reinicias por otra razón y la VM vuelve con una configuración distinta a la que llevaba semanas usando. Si no sabías que había cambios pendientes, parece magia negra. No lo era. Era administración doméstica con poca luz.
antes de reiniciar, también lo miro#
qm pending no solo sirve antes de investigar. También sirve antes de reiniciar.
Si una VM tiene cambios pendientes, un reinicio puede aplicar cosas que no estaban activas. Eso puede ser justo lo que quieres. O puede sorprenderte.
Por eso, antes de reiniciar una VM importante, me gusta lanzar esta mini secuencia.
| |
Si qm pending no muestra nada, el reinicio será más previsible desde el punto de vista de configuración.
Si muestra cambios, paro un momento. ¿Quería aplicar esto ahora? ¿Recuerdo por qué lo cambié? ¿Tiene sentido que la VM vuelva con más RAM, menos CPU, otro orden de arranque o un dispositivo distinto?
No siempre hay que cancelar. Muchas veces el reinicio es justo la oportunidad para aplicar lo pendiente. Pero prefiero saberlo antes.
después de tocar algo, lo uso como confirmación#
También lo uso al final.
Si hago cambios y reinicio, vuelvo a comprobar.
| |
Cuando no devuelve nada, me quedo más tranquilo. No porque eso pruebe que la aplicación esté bien, sino porque al menos la configuración pendiente ya no está jugando al escondite.
Luego miro la VM por dentro, claro. Sistema operativo, servicios, logs y lo que toque. Pero hay una capa menos de incertidumbre.
En problemas raros, quitar capas de incertidumbre es media vida.
no confundir qm config con qm pending#
qm config enseña la configuración de la VM. qm pending enseña diferencias pendientes.
Los dos se complementan, pero no responden lo mismo.
Si solo miro qm config, puedo ver el valor guardado y pensar que todo está aplicado. Si solo miro dentro de la VM, puedo ver el valor activo y pensar que Proxmox no hizo caso. qm pending conecta esas dos realidades.
Es el comando puente.
No lo uso cada vez que abro Proxmox. Sería absurdo. Pero cuando voy a reiniciar, cambiar recursos o investigar algo que no cuadra, sí. Es demasiado barato como para no hacerlo.
cuidado con los cambios acumulados#
El peor escenario no es tener un cambio pendiente. El peor escenario es tener varios y no acordarte de ninguno.
Subiste memoria hace dos semanas. Cambiaste CPU una noche. Tocaste una opción de arranque durante una prueba. Dejaste algo pendiente porque no querías reiniciar en ese momento. La VM siguió funcionando. Tú seguiste con tu vida.
Hasta que un día reinicias.
La máquina vuelve diferente y tú no sabes si el problema viene del reinicio, del update, de la aplicación o de esa lista de cambios que llevaba esperando silenciosamente.
Por eso me gusta revisar pendientes antes de tocar una VM antigua o crítica. Si hay cambios acumulados, los documento en una nota rápida o los aplico en una ventana controlada. Lo que no hago es fingir que no existen.
qué hago si encuentro algo pendiente#
Depende del caso.
Si es una VM de pruebas, normalmente aplico el cambio en cuanto puedo. Reinicio, compruebo y sigo.
Si es una VM importante, primero identifico de dónde viene el cambio. Miro notas, historial de tareas si lo tengo, o simplemente comparo con lo que esperaba. Si el cambio tiene sentido, busco una ventana. Si no tiene sentido, lo revierto antes de que se aplique por accidente.
La parte importante es decidir. Un cambio pendiente sin decisión es deuda técnica con fecha sorpresa.
Y en un homelab ya hay suficientes sorpresas sin fabricarlas uno mismo.
mi rutina práctica#
Cuando una VM no se comporta como espero, suelo hacer esto.
| |
Luego, si hace falta, entro dentro de la VM.
| |
No empiezo dentro si sospecho que la capa de Proxmox puede tener algo pendiente. Prefiero saber primero qué cree el host.
Si voy a cambiar memoria o CPU, hago lo mismo antes y después. Antes para saber de dónde parto. Después para confirmar si queda algo esperando.
Es una rutina pequeña. No tiene glamour. Tampoco lo necesita.
lo que no te dice#
qm pending no te dice si el cambio es buena idea. No sabe si 6 GB de RAM son demasiados o pocos. No sabe si tu aplicación necesita más CPU. No sabe si reiniciar ahora molestará a alguien.
Solo enseña diferencias pendientes.
La decisión sigue siendo tuya. Y eso está bien. El comando no está para pensar por ti. Está para evitar que pienses con datos falsos.
También conviene recordar que una salida vacía no significa que la VM esté sana. Solo significa que no hay cambios de configuración pendientes. Puedes tener una aplicación rota, un disco lleno o un servicio caído con qm pending completamente limpio.
Cada herramienta con su trabajo.
mi opinión#
qm pending es de esos comandos que parecen secundarios hasta que te salva una tarde.
No lo vas a usar para enseñar el homelab en una captura bonita. No impresiona. No hace nada visible. Pero te dice una cosa que la cabeza humana gestiona fatal. Te dice si lo que crees que cambiaste ya forma parte de la realidad o sigue esperando.
En mi Proxmox, eso lo convierte en parte de la revisión básica junto a qm status y qm config. Primero sé si la VM está viva. Luego miro cómo está definida. Después compruebo si hay cambios en cola.
Solo entonces toco.
Parece una manía. Puede ser. Pero las manías buenas son las que evitan perder una noche por una línea que llevaba días avisando en silencio.