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.
Los contenedores LXC en Proxmox tienen una virtud peligrosa. Son tan cómodos que acabas creando más de los que reconoces en público. Un proxy por aquí, una prueba de Debian por allá, un servicio pequeño que no merecía una VM completa, una utilidad que iba a ser temporal y lleva seis meses arrancando sola.
Por eso uso mucho pct config. Antes de cambiar red, memoria, disco, features o permisos de un contenedor, quiero ver su configuración real. No lo que creo que hice. No lo que recuerdo haber dejado. La realidad, con sus líneas feas y sus pequeñas pistas.
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.
Los contenedores LXC son una de las mejores trampas del homelab. Son ligeros, arrancan rápido, consumen poco y por eso mismo acabas creando más de los que deberías. Un proxy temporal. Un DNS de prueba. Un contenedor para una herramienta que querías mirar media hora. Otro para un servicio que al final no usas, pero que sigue ahí porque no molesta.
Hasta que molesta.
Cuando quiero ver qué contenedores viven en un nodo Proxmox, uso esto.
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.
Hay una zona de Proxmox que mucha gente mira solo cuando algo ya ha explotado. Las tareas recientes.
Yo intento mirarlas antes.
Cuando un nodo se comporta raro, una VM aparece apagada, un backup falla o una acción del panel no termina como esperaba, una de las primeras cosas que lanzo es esto.
1 pvesh get /nodes/proxmox-node-3/tasks --limit 12 --output-format yaml Es una forma rápida de preguntarle al nodo qué ha pasado hace poco. No lo que yo creo que pasó. No lo que recuerdo haber tocado mientras tenía tres pestañas abiertas. Lo que Proxmox ha registrado como tarea.
Hay días en los que no quiero abrir el panel de Proxmox. No porque la interfaz sea mala, sino porque a veces necesito una lectura más seca del nodo antes de contaminarme con colores, gráficas y esa falsa tranquilidad que da ver una pantalla cargada.
Para eso uso bastante este comando.
1 pvesh get /nodes/proxmox-node-3/status --output-format yaml pvesh es de esas herramientas que parecen feas hasta que te salva media tarde. Es la API de Proxmox desde la terminal. Lo que ves en la web, con más o menos capas, sale de ahí. Y cuando estoy tocando un nodo concreto, me gusta tener una foto rápida de CPU, memoria, kernel, versión de PVE, disco raíz, swap y uptime sin depender de que el navegador esté fino.
