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.
Por eso, antes de modificar una VM, suelo lanzar esto.
| |
El número cambia, claro. El hábito no. Primero miro la configuración cruda y después decido si el cambio tiene sentido. A veces confirmo lo que esperaba. Otras veces encuentro un detalle que me ahorra media hora de persecución absurda.
la captura real de este post#
La salida de la imagen viene de una VM real de mi laboratorio. He saneado nombre, MAC, UUID y almacenamiento para no enseñar detalles internos, pero la estructura es la que veo cuando reviso una máquina virtual de Proxmox desde terminal.
No es una salida bonita. Me gusta precisamente por eso. La interfaz web te reparte estos datos en varias pestañas. qm config los deja todos encima de la mesa de golpe. Si voy con prisa, prefiero una lista fea que me diga la verdad antes que una interfaz amable que me obligue a ir saltando entre hardware, opciones, cloud-init, backups y notas.
cuándo lo miro#
Lo miro sobre todo en cuatro momentos.
Antes de subir RAM o CPU. Antes de tocar discos. Antes de cambiar red. Antes de reiniciar una VM que lleva semanas viva y que puede tener alguna rareza olvidada.
También lo miro cuando heredo una VM vieja, aunque sea mía. En un homelab, “heredar” una máquina propia es más normal de lo que parece. Montas algo una noche, funciona, pasan dos meses y ya no recuerdas si aquello era una prueba, un servicio serio o una ñapa que sobrevivió por accidente.
qm config corta bastante ese teatro mental. Ves los recursos, el tipo de BIOS, el controlador de disco, el bridge de red, el orden de arranque, las etiquetas y alguna pista sobre cómo nació esa VM. No reemplaza a una documentación decente, pero ayuda cuando la documentación real es una mezcla de notas sueltas, memoria y vergüenza.
cores y memory me dicen si fui generoso de más#
Las dos líneas que mira todo el mundo son estas.
| |
Son sencillas, pero tienen más miga de la que parece. En Proxmox es muy fácil asignar recursos con alegría porque al principio sobra de todo. Dos vCPU aquí, 4 GB allá, otra VM con 8 GB “por si acaso”. Luego miras el nodo un año después y descubres que has convertido el overcommit en una forma de vida.
No digo que esté mal sobreasignar. En casa lo hago. La mayoría de mis VMs no están exprimiendo CPU todo el día. Pero necesito saber cuándo una máquina tiene recursos porque los necesita y cuándo los tiene porque una noche me vine arriba.
Si veo una VM pequeña con 4 GB de RAM y apenas hace nada, me lo apunto para revisar. Si veo una VM crítica con 2 GB y swap sufriendo, también. El comando no decide por mí. Me pone delante la conversación incómoda.
el tipo de CPU importa más de lo que parece#
Esta línea suele pasar desapercibida.
| |
En mi caso suelo preferir host cuando la VM se queda en el mismo nodo o cuando sé bien dónde va a vivir. Da buen rendimiento y expone características del procesador que pueden venir bien. Pero tiene una pega clara. Si quieres migrar entre nodos con CPUs distintas, esa decisión puede darte guerra.
Aquí no hay receta universal. Si la VM forma parte de un cluster donde migro cargas entre mini PCs diferentes, me pienso más el modelo de CPU. Si es una VM muy pegada a un nodo concreto, host me parece razonable. Lo importante es acordarse de que existe antes de culpar a Proxmox cuando una migración no sale tan limpia como esperabas.
qm config me obliga a verlo. Y eso ya compensa.
BIOS, UEFI y arranque#
Estas líneas son de las que miro antes de tocar discos o restaurar backups.
| |
Si una VM usa OVMF, hay disco EFI. Si arrancas en modo SeaBIOS, la historia cambia. Parece un detalle menor hasta que restauras, clonas o mueves una máquina y de pronto no arranca.
El orden de arranque también me interesa. Me gusta saber si la VM está arrancando del disco que creo que está arrancando. En máquinas que han tenido ISOs montadas, discos temporales o pruebas raras, esta línea te puede ahorrar un rato de mirada bovina delante de la consola.
Cuando algo no arranca después de tocar almacenamiento, qm config es uno de los primeros sitios donde miro. No porque vaya a resolverlo todo, sino porque me dice si la definición de la VM tiene sentido antes de meterme en el sistema operativo invitado.
el disco cuenta muchas cosas#
Esta línea suele ser la más jugosa.
| |
Aquí veo almacenamiento, bus, caché, discard, tamaño y alguna pista de intención. Si el disco está en un storage que no esperaba, paro. Si el tamaño no encaja, paro. Si discard no está activo en una VM donde me interesa recuperar espacio, lo reviso. Si veo cache con una opción que no recuerdo haber elegido, lo miro con calma.
En mi lab he tenido varias fases. Primero haces discos donde caben. Luego empiezas a ordenar storage por rendimiento, backup, replicación o simple supervivencia. El problema es que las VMs no se reordenan solas porque tú hayas madurado espiritualmente como administrador doméstico.
Por eso este comando viene bien. Te enseña dónde está cada disco sin obligarte a navegar por el panel. También te ayuda a detectar esas VMs que siguen viviendo en un almacenamiento antiguo porque nadie las movió cuando tocaba.
la red es donde más tonterías se pagan#
La línea de red parece inocente.
| |
Pero aquí se pagan muchas decisiones malas. El bridge define por dónde sale la VM. Si tienes varias redes, VLANs o bridges dedicados, esta línea importa mucho. Una VM en el bridge equivocado puede funcionar lo justo para confundirte y fallar justo donde duele.
También miro que el adaptador sea virtio, salvo casos muy concretos. No quiero descubrir meses después que una VM importante va con un modelo de red raro porque la creé deprisa o porque importé una máquina antigua.
La MAC la suelo sanear en capturas y notas públicas, pero en privado también me sirve para cruzar cosas cuando hay líos de DHCP o reservas. No es lo primero que miro, pero cuando necesitas ese dato, agradeces tenerlo ahí.
onboot separa servicios reales de pruebas olvidadas#
Esta línea me parece más política que técnica.
| |
Si una VM arranca con el nodo, alguien decidió que importa. Ese alguien muchas veces fui yo con sueño. Aun así, la señal cuenta.
Antes de reiniciar un nodo miro qué máquinas tienen onboot activo. Si hay demasiadas, quizá he convertido el arranque del host en una procesión lenta. Si una VM crítica no lo tiene, quizá después de un corte de luz me voy a encontrar un servicio apagado y cara de tonto.
No todo tiene que arrancar solo. De hecho, me gusta que las VMs de pruebas no lo hagan. Pero las importantes deben ser explícitas. onboot es una de esas pequeñas líneas que revela si el homelab está pensado o simplemente acumulado.
las etiquetas ayudan si no las conviertes en decoración#
Las tags me gustan, pero solo si tienen criterio.
| |
Si etiquetas todo como critical, no has etiquetado nada. Si usas nombres distintos cada semana, tampoco. En mi caso intento que las tags me digan al menos dos cosas. Qué tipo de servicio es y cuánto cuidado tengo que tener antes de tocarlo.
Una VM marcada como crítica no debería recibir el mismo trato que una prueba. Parece obvio, pero a las once de la noche todos somos más optimistas de lo recomendable. Ver la etiqueta en la salida me ayuda a bajar una marcha.
También uso tags para filtrar en la interfaz y para recordar contexto cuando vuelvo a una máquina meses después. No son documentación completa, pero son migas de pan útiles.
ojo con lock#
En la captura no lo he dejado como estado activo permanente, pero hay una línea que conviene respetar mucho cuando aparece.
| |
Si una VM está bloqueada por backup, snapshot, migración o alguna operación pendiente, no fuerzo nada por orgullo. Primero entiendo qué operación está en marcha o qué se quedó colgado. Quitar locks a mano puede ser necesario alguna vez, pero no debería ser el primer reflejo.
En un homelab tendemos a normalizar pequeñas barbaridades porque “solo es casa”. Mal enfoque. Casa es justo donde menos apetece perder una tarde por una estupidez propia.
mi rutina rápida antes de cambiar una VM#
Cuando voy a tocar una VM, normalmente hago esto.
| |
qm status me dice si está viva. qm config me enseña la definición actual. qm pending me dice si hay cambios pendientes de aplicar. Ese último comando lo miro menos, pero cuando aparece algo pendiente me alegro de haberlo lanzado.
Después, si voy a tocar recursos, hago el cambio. Si voy a reiniciar, reviso si hay servicios dentro que merecen un apagado ordenado. Si voy a migrar, miro storage y CPU con más cariño.
La gracia no está en el comando. Está en tener una pausa breve antes de actuar. Dos minutos de lectura seca evitan muchas horas de arqueología posterior.
lo que no te dice qm config#
Conviene no pedirle más de lo que da. qm config no te dice si la aplicación dentro de la VM está sana. No sabe si Docker está ardiendo, si una base de datos está sin espacio o si Home Assistant se ha levantado con ganas de drama.
Tampoco te da métricas históricas. Para eso miro monitorización, backups, logs o la propia VM. Este comando responde a otra pregunta. ¿Cómo está definida esta máquina en Proxmox ahora mismo?
Y esa pregunta merece respuesta antes de tocar nada.
mi opinión#
qm config es uno de esos comandos poco vistosos que separan cacharreo con control de cacharreo con fe. No hace falta usarlo cada cinco minutos. Pero antes de cambiar una VM que importa, me parece casi obligatorio.
La interfaz web está bien. Yo la uso mucho. Pero cuando quiero una foto rápida y completa, prefiero terminal. Copio la salida, la comparo, la guardo si hace falta y sigo. Menos clics. Menos suposiciones. Menos drama doméstico.
Y en un homelab, reducir drama ya cuenta como victoria técnica.
Si estás ordenando tu Proxmox, yo lo metería en la misma rutina que qm list, pct list y la revisión de storage con pvesm status. Primero inventario, luego cambios. Parece aburrido. Precisamente por eso funciona.