Hay una clase de problemas en Proxmox que no empieza con un error rojo. Empieza con una decisión pequeña tomada demasiado rápido. Subir RAM a una VM sin mirar cómo está definida. Reiniciar un nodo pensando que no vive nada importante ahí. Mover un disco entre storages sin comprobar snapshots, bus, guest agent o espacio real. Entrar en un LXC como si fuera una VM pequeña y olvidar que comparte más de lo que parece con el host.
Por eso tengo un orden bastante repetido para revisar VMs y contenedores antes de tocar nada. No es una metodología solemne. Es una forma de obligarme a mirar la realidad actual del nodo antes de confiar en mi memoria. En un homelab, la memoria suele mentir con mucha seguridad.
La idea es simple. Primero inventario. Luego configuración. Después estado vivo. Solo al final cambios. Si invierto ese orden, acabo arreglando síntomas, creando locks raros o descubriendo demasiado tarde que la VM que iba a reiniciar era justo la que sostenía el servicio que quería consultar.
primero quiero saber qué vive en el nodo#
Antes de tocar mantenimiento en un nodo, miro las dos listas básicas.
| |
qm list me enseña las máquinas virtuales definidas en ese nodo. pct list hace lo mismo con los contenedores LXC. No busco una captura bonita. Busco una respuesta operativa.
- qué está
running - qué está
stopped, pero sigue ocupando contexto - si hay locks o estados raros
- si el nodo está más cargado de lo que recordaba
- si estoy a punto de interrumpir algo que no quería tocar
Esta comprobación parece demasiado básica hasta que te salva. Más de una vez he entrado pensando que un nodo estaba casi vacío y he visto que seguían ahí una VM de pruebas convertida en servicio real, un contenedor de DNS o una pieza secundaria que no quería reiniciar en ese momento.
Si el nodo tiene carga real, no significa que no pueda tocarlo. Significa que ya no estoy actuando a ciegas.
después separo VM de LXC#
Proxmox hace cómodo mezclar VMs y contenedores, pero no conviene tratarlos igual. Una VM tiene su kernel invitado, sus discos virtuales y una separación más clara. Un LXC vive mucho más cerca del host. Esa cercanía lo hace ligero y rápido, pero también vuelve más importantes los montajes, permisos, features y límites.
Para una VM miro:
| |
Para un contenedor miro:
| |
La diferencia no es solo el comando. En una VM me fijo mucho en CPU, memoria, BIOS, bus de disco, orden de arranque, cloud-init, red y guest agent. En un LXC miro red, rootfs, memoria, swap, features, montajes y cualquier línea lxc.* que sugiera que ese contenedor tiene una relación especial con el host.
Si voy a tocar recursos sin mirar esto antes, me estoy saltando el mapa.
configuración de VM: lo que busco en qm config#
qm config no arregla nada. Precisamente por eso me gusta. Enseña la definición de la VM sin adornarla.
| |
Las primeras líneas que suelo leer son CPU y memoria. No porque sean difíciles, sino porque explican muchas decisiones antiguas.
| |
En casa es normal sobreasignar un poco. El problema aparece cuando no sabes si esos recursos están puestos por necesidad o por entusiasmo nocturno. Si una VM pequeña tiene 8 GB porque una prueba se quedó a medio camino, quizá conviene corregirlo. Si una VM crítica tiene 2 GB y lleva meses justa, quizá el problema no es Proxmox, sino el límite que le dejaste.
Luego miro disco y bus.
| |
Aquí quiero saber dónde vive el disco, qué tamaño tiene, qué controlador usa y si el storage encaja con lo que voy a hacer. Mover, ampliar o restaurar una VM sin entender esto es una buena receta para culpar al almacenamiento equivocado.
También miro arranque y UEFI si voy a tocar discos.
| |
Una VM puede parecer sencilla hasta que descubres que depende de un disco EFI, una controladora concreta o un orden de arranque que nadie documentó. Prefiero verlo antes de cambiar nada.
guest agent: útil, pero solo si existe de verdad#
El QEMU Guest Agent es una de esas piezas que hacen que Proxmox parezca más integrado de lo que realmente está. Cuando está bien instalado, te da IPs, apagados más limpios y operaciones más cómodas. Cuando crees que está instalado y no lo está, genera confianza falsa.
Antes de depender de él, lo compruebo.
| |
Si responde, bien. Si no responde, no dramatizo, pero cambio mi plan. No asumo que Proxmox pueda pedirle al invitado todo lo que yo quería. No confío en una IP leída desde el agente. No baso un apagado limpio en una integración que quizá no existe.
Para ver red desde fuera, cuando el agente está disponible, también puede ayudar:
| |
Esto es muy útil cuando una VM perdió SSH, cambió de DHCP o no sabes qué IP cogió. Pero insisto en el matiz: es útil si el agente responde. Si no, toca volver a red, consola o DHCP, no inventarse certezas.
cambios pendientes y locks antes de reiniciar#
Antes de reiniciar o tocar una VM que lleva tiempo viva, miro cambios pendientes.
| |
Un cambio pendiente no siempre es un problema. A veces es justo lo que esperabas aplicar en el siguiente reinicio. Pero si no lo recuerdas, ya tienes una pista importante. Reiniciar una VM con cambios pendientes olvidados puede convertir una operación inocente en una sorpresa.
También miro locks cuando algo no cuadra.
| |
Y con LXC igual:
| |
No me gusta desbloquear por reflejo. qm unlock existe y a veces salva, pero también puede tapar una tarea real a medias. Si hay lock, primero busco qué operación lo dejó ahí. Backup, snapshot, migración, disco, restauración. Después decido.
apagar no es tirar del cable#
Para apagar una VM, mi primera opción suele ser:
| |
Si no responde, espero y miro estado.
| |
qm stop lo dejo para cuando ya acepté que voy a cortar por lo sano.
| |
La diferencia importa. En un homelab es tentador ir rápido porque todo parece nuestro y cercano. Pero una VM con base de datos, cola, filesystem sensible o servicio familiar no agradece que la trates como una regleta. Primero apagado ordenado. Luego diagnóstico. Solo al final fuerza.
Con LXC hago algo parecido. Puedo entrar con:
| |
O ejecutar algo puntual sin abrir una sesión interactiva:
| |
Pero intento no confundir comodidad con inocuidad. Un LXC no es una caja mágica aislada del mundo. Si tiene montajes del host, permisos especiales o Docker dentro, tocar dentro puede tener consecuencias fuera.
mover, ampliar o rescatar discos pide más calma#
Las operaciones de disco son donde más me obligo a frenar. Para ampliar un disco, por ejemplo, no basta con lanzar:
| |
Antes quiero saber tres cosas. Dónde vive el disco. Si el invitado sabe crecer el filesystem. Y si tengo backup o snapshot con sentido. Proxmox puede ampliar el disco virtual, pero dentro de la VM todavía queda trabajo. Si mezclo esas capas, acabo pensando que Proxmox falló cuando en realidad solo faltaba extender partición o filesystem.
Para mover un disco entre storages:
| |
Aquí miro espacio, tipo de storage, rendimiento esperado y basura posterior. No todos los movimientos son iguales. No es lo mismo mover un disco pequeño de una VM apagada que tocar una VM grande, viva y con snapshots.
Cuando algo no aparece como esperaba, antes de culpar al storage puedo forzar una lectura:
| |
No es magia. Es una forma de decirle a Proxmox que vuelva a mirar discos que quizá existen pero no están integrados como esperas.
migrar una VM no debería ser un acto de fe#
Antes de migrar una VM, reviso tres capas. Configuración, storage y CPU.
| |
Si la VM usa cpu: host, me pregunto si los nodos son realmente compatibles. Si el disco vive en storage local, la migración no se parece a una VM sobre storage compartido. Si depende de passthrough, USB o algo pegado al nodo, quizá no debería migrar sin rediseñar antes.
El comando puede ser tan simple como:
| |
Pero el éxito depende de lo que había debajo. Por eso no me impresiona que el comando sea corto. Me importa si el contexto está limpio.
LXC: lo que miro antes de cambiarlo#
En contenedores, pct config me da casi todo lo importante.
| |
Miro rootfs, memoria, swap, red, features, montajes y cualquier opción que sugiera privilegios especiales. Si veo nesting=1, ya sé que ese contenedor puede estar haciendo algo más delicado, como Docker dentro. Si veo montajes del host, dejo de tratarlo como una pieza aislada. Si veo límites muy bajos, no culpo al servicio antes de culpar a la jaula.
Para cambios de recursos:
| |
No lo lanzo solo porque el contenedor va lento. Primero miro si realmente le falta memoria, si está usando swap, si el host va justo o si el servicio interno es el problema. Subir recursos puede ser correcto. También puede ser una forma elegante de esconder deuda.
Para mover archivos, pct push y pct pull son cómodos:
| |
Los uso, pero con cuidado. Si estoy tocando configuración productiva, prefiero copia previa y cambio pequeño. La comodidad de no abrir SSH no elimina la necesidad de saber qué archivo estás pisando.
mi checklist corto antes de tocar nada#
Cuando voy con prisa, uso esta lista mental.
qm listypct listpara saber qué vive en el nodo.qm configopct configpara ver la definición real.qm status,qm pendingy guest agent si aplica.- Locks y tareas recientes si algo no cuadra.
- Storage y backups antes de discos, migraciones o ampliaciones.
- Apagado limpio antes de usar fuerza.
- Cambio pequeño, verificación inmediata y nota si la pieza es importante.
No evita todos los problemas. Sí evita los tontos, que son los que más rabia dan.
la regla de fondo#
Proxmox no suele fallar porque falten comandos. Suele fallar porque usamos comandos correctos con una lectura incompleta. qm, pct y pvesh dan mucha información, pero hay que usarlos como secuencia, no como impulsos sueltos.
Primero miro qué existe. Luego cómo está definido. Luego si está vivo y sano. Después decido. Ese orden me ha ahorrado más sustos que cualquier panel bonito.
Y si después de revisar todo sigo teniendo dudas, prefiero parar diez minutos antes que fabricar una tarde entera de reparación. En un homelab, la paciencia también es una herramienta de alta disponibilidad.