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.
Y cuando no lo son, pierdes tiempo de la forma más cutre posible. Abres el router. Miras leases. Entras en la interfaz de Proxmox. Buscas en notas. Pruebas un ping. Pruebas otro. Te preguntas si la VM está arrancada, si cloud-init hizo lo que tenía que hacer o si simplemente estás mirando la máquina equivocada.
Yo prefiero preguntar directamente al invitado, siempre que tenga QEMU Guest Agent funcionando.
| |
Si el agente responde, Proxmox te devuelve las interfaces que ve la VM, sus MACs, sus IPs y algunas estadísticas básicas. No es una auditoría completa de red, pero para salir de dudas rápido va muy bien.
la captura de este post#
La captura parte de una salida real de una VM de mi laboratorio, saneada para quitar datos privados. He cambiado MACs e IPs por valores genéricos, pero he mantenido la estructura que devuelve Proxmox.
La idea se entiende rápido. Ejecutas el comando y buscas la interfaz que no sea lo.
| |
En una VM sencilla verás algo parecido a esto.
| |
La parte que normalmente busco es esta.
| |
Y con eso ya puedo dejar de adivinar.
requisito previo: el guest agent#
Este comando depende del QEMU Guest Agent. Si el agente no está instalado, parado o no activado en Proxmox, no esperes milagros.
Antes de usarlo, suelo comprobar el canal con una prueba más pequeña.
| |
Si responde bien, sigo. Si falla, no tiene sentido pedir interfaces al invitado. Primero hay que arreglar el agente o entrar por otra vía.
Esto es importante porque network-get-interfaces no está mirando la configuración del host Proxmox. Está preguntando al sistema invitado. Esa es su gracia y también su limitación.
Proxmox puede saber qué tarjeta virtual tiene conectada una VM. Puede saber si está en un bridge u otro. Puede saber la MAC configurada. Pero la IP final vive dentro del invitado, salvo que tengas todo atado con DHCP y reservas perfectamente mantenidas.
El guest agent cruza esa frontera.
por qué lo uso en vez de mirar solo el router#
Mirar el router o el servidor DHCP está bien. Lo hago muchas veces. Pero no siempre responde a la pregunta correcta.
El DHCP puede tener leases antiguos. Puede enseñar una IP entregada hace rato, aunque la VM ya no la tenga activa. Puede no ver una interfaz con IP fija. Puede no enseñarte una segunda interfaz en otra red. Puede estar en otro sitio si tienes varias VLANs o varios segmentos.
La VM, en cambio, te dice lo que ella ve.
Eso no significa que la VM tenga razón absoluta para todo. Una interfaz puede tener IP y no tener conectividad real. Una ruta puede estar mal. Un firewall puede bloquear tráfico. Un bridge puede estar roto. Pero para la pregunta inicial, saber qué IP tiene dentro el sistema es oro.
Me ha ahorrado bastantes paseos tontos por paneles.
el caso típico: clonar una plantilla#
Este comando me parece especialmente útil después de clonar una plantilla.
Creas una VM nueva desde una plantilla Debian o Ubuntu. Cloud-init debería asignar hostname, usuario, clave SSH e IP por DHCP. Todo parece correcto. Arranca. Proxmox dice running. Pero no recuerdas qué IP le ha caído.
Podrías ir al DHCP. Podrías escanear la red. Podrías abrir consola y hacer login. O puedes lanzar esto desde el nodo.
| |
Si la plantilla está bien hecha y el guest agent arranca, la IP aparece ahí.
Es una de esas pequeñas recompensas por haber preparado bien la plantilla. El trabajo aburrido de instalar qemu-guest-agent, activarlo y dejarlo en el arranque te devuelve tiempo cada vez que creas una VM nueva.
Si la plantilla no tiene agente, vuelves al método cavernícola. Consola, router, búsqueda manual y paciencia.
leer la salida sin volverse loco#
La salida puede ser más larga de lo que esperas. No porque sea complicada, sino porque incluye detalles que quizá no necesitas en ese momento.
Normalmente verás lo, que es loopback. Esa interfaz no te ayuda a encontrar la VM desde la red.
| |
Después vendrán interfaces reales. En Linux pueden llamarse eth0, ens18, ens19 o cualquier nombre predecible moderno de systemd. En Windows verás nombres distintos.
Lo que busco primero es una IPv4 privada del segmento donde espero tener la VM. En ejemplos públicos uso 192.168.1.x, pero en tu homelab puede ser otro rango.
También miro si hay varias interfaces. Esto pasa mucho en VMs que separan red de gestión, red de servicios, red de almacenamiento o pruebas raras. Si ves dos interfaces con IPs distintas, no asumas que la primera es la buena. Mira el bridge en la configuración de Proxmox y confirma qué red corresponde a cada NIC.
Para ver la configuración de red desde Proxmox uso algo así.
| |
Ahí puedo cruzar MAC y bridge. Si la MAC que aparece en network-get-interfaces coincide con net0, ya sé qué interfaz del invitado corresponde a esa tarjeta virtual.
no confundas IP visible con servicio disponible#
Este comando te dice IPs. No te dice que el servicio que quieres usar esté funcionando.
Esto parece una obviedad, pero en diagnósticos reales se olvida mucho. Ves una IP y piensas que ya está. Luego intentas abrir la web de la aplicación y no responde. Entonces empiezas a culpar a Proxmox, al bridge o al DNS.
Puede ser cualquiera de esas cosas, claro. Pero también puede ser que el servicio esté parado dentro de la VM.
Mi orden mental suele ser este.
Primero confirmo estado de VM.
| |
Luego confirmo guest agent.
| |
Luego saco interfaces.
| |
Después pruebo conectividad desde donde toque.
| |
Si ping responde pero curl no, la IP no era el problema principal. Si ni siquiera ping responde, miro firewall, ruta, bridge, VLAN o si estoy probando desde el sitio equivocado.
La ventaja es que ya no estoy adivinando la IP. He quitado una variable.
varias NICs y el falso culpable#
Donde más cuidado tengo es con VMs que tienen varias tarjetas.
Una VM puede tener una interfaz en red de gestión y otra en red de servicios. O una red interna para almacenamiento y otra para salida. Si lanzas network-get-interfaces y copias la primera IP que ves, quizá estás usando la red equivocada.
Me ha pasado. No es un fallo noble.
La forma decente de leerlo es cruzar tres cosas.
La MAC en la salida del agente.
| |
La línea de red de Proxmox.
| |
Y la red en la que esperas encontrar el servicio.
Si todo encaja, bien. Si no encaja, no fuerces la historia. A veces la VM está perfecta y el humano está intentando entrar por la puerta equivocada. Qué cosa más rara, jamás nos ha pasado.
filtrar la salida#
La salida completa en JSON está bien para leer una vez, pero si solo quieres encontrar IPs puedes filtrarla. Con jq queda bastante cómodo.
| |
La salida queda más seca.
| |
No siempre lo hago. Para una revisión manual me basta con leer el JSON. Pero si estoy metiendo esto en un script o quiero revisar varias VMs, filtrar ayuda.
También puedes combinarlo con una lista de VMs, aunque ahí conviene no montar un script agresivo que golpee todo el cluster sin necesidad. En un homelab pequeño no pasa nada. En un entorno más serio, mejor ir con calma.
cuando devuelve demasiada información#
Algunas VMs devuelven estadísticas de paquetes, bytes recibidos, bytes enviados y detalles que no buscabas. No me molesta, pero tampoco lo convierto en análisis de rendimiento.
Esas estadísticas pueden servir como pista. Si una interfaz tiene contadores a cero cuando esperabas tráfico, algo huele raro. Si ves una interfaz con paquetes pero sin IP útil, puede haber configuración parcial. Pero no es mi herramienta principal para rendimiento de red.
Para eso prefiero mirar dentro del sistema, usar métricas, revisar logs o hacer pruebas explícitas.
Aquí el valor está en la identificación rápida.
Qué interfaces existen. Qué MAC tienen. Qué IPs ve el invitado.
Con eso ya puedes orientar el siguiente paso.
fallos habituales#
El fallo más común es que el agente no esté disponible.
| |
En ese caso no arreglas network-get-interfaces. Arreglas el guest agent.
Otro fallo típico es que la VM esté recién arrancada y todavía no tenga red lista. Si lanzas el comando demasiado pronto, puedes ver una salida parcial o sin la IP que esperas. Espera unos segundos y repite antes de sacar conclusiones.
También puede pasar que cloud-init haya fallado. La VM arranca, el agente responde, pero no recibe la configuración de red esperada. Ahí este comando es útil precisamente porque enseña la realidad incómoda. La VM no tiene la IP que tú creías.
Y luego está el clásico de varias interfaces. Si una VM tiene eth0 y ens19, no copies la primera IP por reflejo. Cruza MACs y bridges.
seguridad y privacidad#
No publiques salidas reales sin sanear.
Una salida de network-get-interfaces puede enseñar MACs, rangos internos, nombres de interfaces, IPv6 locales y a veces suficiente información como para dibujar parte de tu red. En una captura privada no pasa nada. En un post público, mejor limpiar.
Para documentación pública uso IPs genéricas como 192.168.1.x, MACs inventadas y nombres de VM neutros. El aprendizaje no necesita enseñar mi red real.
Esto aplica también a tickets, foros y capturas enviadas a terceros. Cuantos menos detalles internos regales, mejor.
cómo lo uso en mi día a día#
Mi uso real es poco glamuroso.
Creo una VM. Arranca. No sé qué IP tiene.
| |
La encuentro. Entro por SSH. Sigo.
Otra situación. Una VM deja de responder por nombre DNS. No sé si es DNS, DHCP, firewall o aplicación.
| |
Si la IP cambió, ya tengo una pista. Si la IP está bien, miro DNS o servicio. Si no hay IP, miro red dentro de la VM. Si el agente no responde, cambio de vía.
No hay épica. Hay menos pérdida de tiempo.
mi opinión#
qm guest cmd network-get-interfaces no es un comando para impresionar a nadie. Es un destornillador.
Lo usas cuando necesitas quitar una duda concreta sin abrir cinco paneles. Y eso, en un homelab, tiene mucho valor.
Me gusta especialmente porque premia hacer bien las bases. Si tus plantillas tienen QEMU Guest Agent, si tus VMs lo arrancan, si Proxmox tiene el canal activado, puedes mirar desde fuera lo justo para orientarte. Si no preparaste nada, vuelves a perseguir IPs como si fuera 2009.
Tampoco lo convertiría en dependencia absoluta. Hay que saber entrar por consola, mirar DHCP, revisar bridges y entender la red. Pero como primera lectura rápida, me parece comodísimo.
La pregunta que responde es pequeña, pero aparece todo el tiempo.
¿Qué IP tiene esta VM?
Cuando un comando te responde eso sin hacerte cambiar de contexto, se gana un sitio en la caja de herramientas.