qm status es uno de esos comandos que parecen tan pequeños que casi da pereza escribir sobre ellos. Te dice si una VM está arrancada, parada o en un estado intermedio. Ya está. Cero épica.
Y aun así lo uso constantemente.
En Proxmox hay comandos mucho más jugosos. qm config te enseña toda la definición de la máquina. qm monitor te deja hablar con QEMU. pvesh te abre media API desde terminal. Pero cuando estoy delante de una VM y voy a tocar algo, la primera pregunta no es sofisticada. La primera pregunta es bastante básica.
¿Esta máquina está viva ahora mismo?
Parece obvio. No lo es tanto cuando llevas varias pestañas abiertas, estás conectado por SSH a un nodo, vienes de mirar la interfaz web hace diez minutos y tienes en la cabeza una mezcla de VMs, contenedores, backups y tareas pendientes. En ese contexto, lanzar qm status antes de actuar no es perder tiempo. Es dejar de fiarte de una foto mental que puede estar caducada.
Yo lo veo como el gesto de mirar si hay corriente antes de desmontar un enchufe. No arregla nada, pero te evita empezar con una tontería.
la captura de este post#
La salida viene de una VM real de mi laboratorio, con nombres y datos internos saneados. He dejado lo importante para que se entienda cómo lo leo sin publicar detalles que no aportan nada.
La versión corta es casi insultantemente simple.
| |
Y devuelve algo así.
| |
La versión con más detalle añade --verbose.
| |
Ahí aparecen más datos, algunos útiles y otros que solo miro cuando estoy estrechando el cerco. Lo importante es que el comando me da una respuesta inmediata desde el nodo, sin depender de que la interfaz web haya refrescado bien o de que yo recuerde el estado correcto.
por qué no me basta con mirar la web#
Uso la interfaz de Proxmox todos los días. No soy de esos que convierten la terminal en religión. La web de Proxmox está bastante bien y para muchas tareas es más cómoda.
Pero para comprobar estado antes de tocar una VM, prefiero terminal.
El motivo es muy simple. Cuando estoy en SSH, ya estoy en el sitio donde voy a actuar. Si voy a ejecutar qm shutdown, qm stop, qm set, qm migrate o cualquier otra operación, quiero confirmar el estado en la misma sesión y con el mismo contexto. No quiero depender de una pestaña del navegador que quizá lleva abierta veinte minutos.
También me ayuda a frenar el piloto automático. Hay una diferencia enorme entre pensar “esta VM estaba apagada” y ver en pantalla status: running. La primera frase es una suposición. La segunda es una señal.
Y en un homelab, muchas cagadas nacen de suposiciones pequeñas.
la salida corta: status#
La lectura básica es esta.
| |
Puede parecer poco, pero ya cambia la decisión.
Si la VM está running, no la trato como un objeto inerte. Me pregunto qué hay dentro, si alguien o algo depende de ella, si conviene apagar desde el sistema invitado o si puedo reiniciarla sin drama.
Si está stopped, la conversación cambia. Quizá puedo modificar recursos con menos miedo. Quizá puedo revisar configuración sin preocuparme por impacto inmediato. Quizá descubro que el problema no es que el servicio vaya mal, sino que la VM ni siquiera arrancó después del último mantenimiento.
También pueden aparecer estados menos cómodos. paused, suspended o estados relacionados con operaciones en curso. Ahí no fuerzo nada por orgullo. Primero miro qué está pasando.
La clave es no leer qm status como un diagnóstico completo. No lo es. Es una puerta de entrada.
cuándo lo lanzo#
Tengo varios momentos donde lo uso casi por reflejo.
Antes de apagar una VM.
| |
Antes de forzar una parada, todavía más.
| |
Antes de cambiar CPU o memoria.
| |
Antes de investigar por qué una máquina no responde por red.
| |
Esto último parece tonto, pero me ha ahorrado varias vueltas absurdas. Si una VM no responde por SSH, no empiezo culpando a DNS, VLANs o al firewall sin mirar antes si la VM está arrancada. Sí, suena básico. También es justo lo básico lo que más se olvida cuando vas con prisa.
--verbose cuando necesito una foto un poco más rica#
La opción --verbose no convierte qm status en una herramienta de monitorización seria, pero añade contexto.
Puedes ver memoria, CPU asignada, tráfico de red acumulado, lecturas y escrituras de disco, PID del proceso QEMU, uptime y estado QMP. No todo lo miro siempre. De hecho, la mayoría de las veces no hace falta.
Pero hay tres campos que sí me interesan cuando algo huele raro.
pid#
Si aparece un PID, hay un proceso QEMU vivo en el nodo. Esto no garantiza que el sistema invitado esté sano, pero confirma que Proxmox tiene la VM corriendo como proceso.
Cuando una máquina aparece como viva pero no responde, el PID me recuerda que tengo dos capas distintas. Una cosa es QEMU. Otra es el sistema operativo dentro de la VM. Otra es la aplicación que corre dentro. Mezclar esas capas es una forma rápida de diagnosticar mal.
uptime#
El uptime me ayuda a detectar reinicios recientes. Si una VM que yo creía estable lleva viva pocos minutos, algo pasó. Quizá la reinició una actualización. Quizá hubo un mantenimiento. Quizá falló y alguien la levantó a mano. Quizá fui yo y no me acuerdo, que también pasa.
No saco conclusiones grandes solo con uptime, pero sí me da una pista para mirar logs con una ventana temporal más concreta.
qmpstatus#
qmpstatus viene del estado que QEMU reporta por su interfaz de monitorización. En una VM sana suele acompañar al estado general, pero cuando ves diferencias raras merece la pena no ignorarlas.
No es mi primer dato del día. Tampoco lo convierto en un oráculo. Pero si estoy revisando una VM complicada, verlo junto al estado general me ayuda a separar “Proxmox cree que está corriendo” de “todo dentro funciona”.
lo que qm status no sabe#
Este punto importa.
qm status no sabe si tu base de datos está bien. No sabe si Docker dentro de la VM está caído. No sabe si el disco invitado está lleno. No sabe si una actualización rompió Nginx. No sabe si Home Assistant se ha levantado con cara de lunes.
Solo te dice el estado de la VM desde Proxmox.
Y eso está bien. Pedirle más sería injusto. Para salud de servicios uso otros comandos, monitorización, logs y pruebas desde dentro. qm status responde una pregunta más estrecha, pero la responde rápido.
Me gusta precisamente por eso. En vez de intentar ser una navaja suiza, es una luz verde o roja inicial.
el patrón que uso antes de tocar una VM#
Mi rutina corta suele ser esta.
| |
Primero estado. Luego configuración. Luego cambios pendientes.
Si la VM está corriendo y voy a tocar algo que requiere reinicio, ya sé que tengo que planificarlo un poco. Si qm config me enseña un disco en un storage que no esperaba, paro. Si qm pending muestra memoria o CPU pendientes, no sigo como si nada.
Esta secuencia no es brillante. Es aburrida. Justo por eso funciona.
El homelab suele romperse menos por falta de comandos avanzados y más por falta de pausas pequeñas. Dos minutos mirando el estado real antes de actuar valen más que veinte minutos arreglando una decisión tomada con prisa.
un ejemplo realista#
Imagina que una VM no responde por SSH. El reflejo malo sería entrar directo a tocar red, reiniciar servicios desde consola o culpar al firewall.
Yo prefiero empezar así.
| |
Si está stopped, ya tengo una explicación bastante contundente. Miro por qué no arrancó, reviso tareas recientes y después decido.
Si está running, sigo.
| |
Ahí miro uptime, bridge de red, recursos y si hay algo raro en la definición. Después ya puedo entrar por consola, revisar logs del sistema invitado o mirar el firewall. Pero entro con una base.
No es que qm status resuelva el caso. Es que evita empezar en el sitio equivocado.
cuidado con qm stop#
Lo menciono porque es una tentación clásica.
Ver que una VM está viva y no responde no significa que haya que lanzar qm stop como primer martillazo. qm stop corta la VM de forma brusca. A veces hace falta. Muchas veces es una mala idea si puedes probar antes qm shutdown, entrar por consola o entender qué está pasando.
Mi regla doméstica es sencilla. Si la VM importa, intento apagado limpio primero. Si está congelada de verdad, si no hay respuesta y si el servicio puede asumir el corte, entonces fuerzo. Pero no convierto el botón rojo en rutina.
qm status ayuda porque me coloca delante del estado antes de esa decisión. No decide por mí. Me obliga a mirar.
cómo encaja con qm config y qm pending#
El post anterior sobre qm config iba de leer la definición de una VM antes de tocarla. Este comando encaja antes de eso.
qm status me dice si está viva.
qm config me dice cómo está definida.
qm pending me dice si hay cambios esperando reinicio o aplicación.
Juntos forman una mini revisión bastante decente. No sustituye a documentación ni a monitorización, pero reduce mucho el margen de actuar por memoria.
Si solo pudiera quedarme con una idea, sería esta. No cambies recursos de una VM mirando solo la interfaz o recordando cómo crees que estaba. Pregunta al nodo.
mi opinión#
qm status no va a impresionar a nadie. No sirve para presumir de homelab ni para hacer capturas espectaculares. Es un comando seco que devuelve una respuesta pequeña.
Pero esa respuesta pequeña aparece justo cuando más falta hace.
Antes de apagar. Antes de reiniciar. Antes de tocar recursos. Antes de investigar una caída. Antes de convertir un problema simple en una expedición por capas que no tocaban.
Por eso lo tengo tan metido en la mano. En mi Proxmox, mirar estado antes de actuar es una norma de higiene. No porque sea complicado, sino porque es demasiado fácil saltárselo.
Y si algo he aprendido montando máquinas en casa es que el homelab no siempre necesita más automatización. A veces necesita que el humano mire una línea antes de darle al martillo.