Antes de tocar discos en Proxmox uso qm disk rescan con dry-run, cruzo la salida con pvesm status y separo problemas de storage, discos unused y tamaños que el invitado todavía no ve.
Uso qm shutdown como apagado normal y qm stop como corte de emergencia. La diferencia importa cuando hay bases de datos, HA, locks o servicios que todavía están cerrando dentro de la VM.
qm guest cmd network-get-interfaces tiene un nombre demasiado largo para algo que hace una pregunta bastante humana.
¿Qué IP tiene esta VM ahora mismo?
No la IP que creo que tiene. No la que apunté en una nota hace tres semanas. No la que sale en una reserva DHCP que quizá ya no aplica. La que el sistema invitado está viendo desde dentro en este momento.
En un homelab con pocas máquinas puede parecer una tontería. En cuanto empiezas a tener varias VMs, plantillas, clones, redes de pruebas, servicios movidos y algún cambio de DHCP hecho con prisa, deja de serlo. La IP de una VM es uno de esos datos que parecen obvios hasta que no lo son.
qm agent ping es una de esas comprobaciones que no lucen nada en una captura, y quizá por eso me gusta tanto.
No te enseña una tabla enorme. No te dibuja una gráfica. No te da una conclusión dramática. Si todo va bien, normalmente no devuelve nada. Y aun así, cuando estoy delante de una VM en Proxmox y quiero saber si puedo hablar con el sistema invitado desde fuera, es una de las primeras cosas que lanzo.
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ó.
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.
Hay comandos que uso porque hacen cosas espectaculares y comandos que uso porque me evitan hacer el ridículo. qm config pertenece claramente al segundo grupo. No arranca nada, no migra nada, no arregla nada por arte de magia. Te enseña cómo está definida una VM en Proxmox, que ya es bastante cuando estás a punto de tocar CPU, RAM, disco, red o arranque.
En un homelab pequeño es muy fácil confiar demasiado en la memoria. Recuerdas que esa VM tenía 4 GB de RAM. Crees que estaba en local-zfs. Jurarías que arrancaba desde scsi0. También pensabas que aquella prueba temporal la habías borrado hace tres semanas y sigue ahí, mirándote desde la lista de máquinas apagadas. La memoria humana y Proxmox no deberían mezclarse sin supervisión adulta.
Hay una diferencia bastante grande entre saber que un nodo Proxmox tiene VMs y saber qué VMs tiene ahora mismo, en qué estado están y cuánto están consumiendo. Parece una tontería hasta que vas a reiniciar, actualizar, mover una carga o investigar por qué un nodo está más cargado que los demás.
Para esa primera mirada uso mucho este comando.
1 pvesh get /nodes/proxmox-node-3/qemu --output-format yaml No tiene misterio. Le pido al nodo su lista de máquinas virtuales QEMU y Proxmox me devuelve una foto bastante útil. Estado, CPUs asignadas, memoria máxima, memoria usada, disco máximo, tráfico de red, uptime, tags y VMID.
