Consola serie

Capturado el 2026-07-28 desde uno de los CE de esta implementación. sitecli/capture-manifest.json registra qué nodo, y scripts/capture-sitecli.sh --check vuelve a verificar la superficie de comandos contra un CE en vivo.

La Consola serie de Azure se conecta al puerto serie emulado del nodo a través de la plataforma Azure. No atraviesa el plano de control de F5 Distributed Cloud, ni el plano de datos del nodo, ni ninguna ruta de red que el nodo controle, que es precisamente por lo que funciona cuando nada más lo hace.

Recurra a ella cuando un CE nunca llegó a arrancar: la registración falló, el sitio no aparece en el tenant, o el nodo está activo pero no tiene ruta de salida. En todos esos casos la API de depuración no tiene túnel por el que retransmitir. SSH sobrevive a una registración fallida, pero solo si su clave ya se escribió en el primer arranque y puede alcanzar la dirección interna del nodo desde dentro de la VNet, y ninguna de las dos cosas es cierta en un nodo con el que se encuentra por primera vez.

Pruebe Site Console antes que esta si el nodo tiene alguna ruta de red operativa: también sobrevive a una registración fallida, no necesita clave y no expulsa a quien ya esté mirando el nodo. La consola serie es lo que queda cuando lo que está roto es la propia ruta de red.

Requisito previo: diagnósticos de arranque

Azure exige los diagnósticos de arranque en la VM antes de conectar una consola serie. Esto lo habilita terraform/modules/ce-node:

boot_diagnostics {}

Un bloque vacío selecciona almacenamiento gestionado por Azure, de modo que no hay cuenta de almacenamiento de diagnósticos, ni política de ciclo de vida, ni clave de acceso que mantener. Confírmelo en un nodo:

az vm show -g <resource-group> -n <vm-name> --query diagnosticsProfile

{ "bootDiagnostics": { "enabled": true } }

Habilitarlo no es retroactivo

Los diagnósticos de arranque capturan el registro serie en el arranque. Activarlos en una VM que ya está en ejecución no produce un registro del arranque que ya ocurrió, por lo que az vm boot-diagnostics get-boot-log responde:

<Error><Code>BlobNotFound</Code><Message>The specified blob does not exist.

Eso es lo esperado, no un fallo. El registro de arranque existe después del siguiente reinicio del nodo. La conexión en vivo a la consola, en cambio, funciona de inmediato: no depende del registro.

Comprobar la disponibilidad sin un terminal

Conectarse requiere una sesión interactiva, pero saber si se conectaría son dos llamadas a la API. Ambas son útiles en una comprobación de estado.

El servicio debe estar habilitado para la suscripción; un administrador puede deshabilitarlo para todo el tenant:

az rest --method get --url \
  "https://management.azure.com/subscriptions/<sub>/providers/Microsoft.SerialConsole/consoleServices/default?api-version=2018-05-01"

{ "properties": { "disabled": false } }

Después, solicite una conexión al puerto serie de un nodo concreto:

az rest --method post \
  --headers "Content-Type=application/json" --body '{}' --url \
  "https://management.azure.com/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Compute/virtualMachines/<vm>/providers/Microsoft.SerialConsole/serialPorts/0/connect?api-version=2018-05-01"

Un connectionString que empiece por wss:// — en esta implementación eastus.gateway.serialconsole.azure.com — significa que la consola es conectable ahora mismo. Antes de que se habilitaran los diagnósticos de arranque, esta llamada no tenía nada a lo que conectarse.

Esa cadena de conexión es una credencial

Es un token de portador de corta duración incrustado en una URL. No lo registre, no lo pegue en un ticket ni lo confirme en un repositorio. Imprima solo el host cuando esté demostrando que la llamada funcionó.

Conectarse

1. Instale la extensión una vez:

   az extension add --name serial-console

2. Conéctese:

   az serial-console connect -g <resource-group> -n <vm-name>

3. Aterriza en el propio prompt de inicio de sesión del nodo, no en un shell, detrás del aviso de auditoría del dispositivo. La consola serie demuestra que el canal funciona; no elude la autenticación.

   Qué credencial acepta el inicio de sesión serie no está verificado

   Nadie ha completado un inicio de sesión por consola serie en esta implementación, así que esta página no indica qué escribir. admin es la cuenta del dispositivo cuyo shell es el Site CLI, y esa misma cuenta se autentica en Site Console con una contraseña, pero no se ha demostrado que una contraseña funcione en el inicio de sesión por consola serie, y sshd es solo por clave para admin, de modo que las dos rutas de credenciales son demostrablemente distintas.

Capturado desde f5-xc-ce-vm-01, con una elisión en el medio donde la salida de las unidades de systemd no aporta nada:

+-----------------------------------------------+
Connected to the serial port of the VM.
If no login prompt is displayed, press ENTER.
+-----------------------------------------------+


Probing EDD (edd=off to disable)... ok
Memory KASLR using RDRAND RDTSC...
init_cea_offsets KASLR using RDRAND RDTSC...
Poking KASLR using RDRAND RDTSC...

Welcome to Red Hat Enterprise Linux 9.2024.6.3 (Plow) dracut-057-44.git20230822.el9 (Initramfs)!

[  OK  ] Started Dispatch Password …ts to Console Directory Watch.

... [320 lines of systemd unit output elided]

[  OK  ] Started Serial Getty on ttyS0.
[  OK  ] Reached target Login Prompts.
[  OK  ] Started OpenSSH server daemon.
[  OK  ] Started Container Runtime Interface for OCI (CRI-O).
[   19.960784] cloud-init[1311]: Cloud-init v. 23.1.1-12.el9_3 running 'modules:config' at Sun, 26 Jul 2026 13:13:54 +0000. Up 19.84 seconds.
[  OK  ] Finished Apply the settings specified in cloud-config.
         Starting Execute cloud user/final scripts...
[  OK  ] Started Docker Application Container Engine.
         Starting Argo Watch service...
         Starting VP Manager image load...
[  OK  ] Started Argo Watch service.
[   21.544663] cloud-init[1512]: Cloud-init v. 23.1.1-12.el9_3 running 'modules:final' at Sun, 26 Jul 2026 13:13:56 +0000. Up 21.41 seconds.
[   22.751629] cloud-init[1512]: Cloud-init v. 23.1.1-12.el9_3 finished at Sun, 26 Jul 2026 13:13:57 +0000. Datasource DataSourceAzure [seed=/var/lib/waagent].  Up 22.37 seconds
[  OK  ] Finished Execute cloud user/final scripts.
[  OK  ] Started libcontainer conta…f4b59f3b96c31ee10cd95f6eb371c.


UNAUTHORIZED ACCESS TO THIS DEVICE IS PROHIBITED
All actions performed on this device are audited
f5-xc-ce-vm-01 login: [  123.107074] Warning: Deprecated Driver is detected: iptables will not be maintained in a future major release and may be disabled
[  123.144641] Warning: Deprecated Driver is detected: ip6tables will not be maintained in a future major release and may be disabled

En esa transcripción hay cuatro cosas que merece la pena observar, porque responden preguntas que la API de depuración no puede:

• cloud-init se completó — Datasource DataSourceAzure, finalizado a los 22,37 segundos. Un nodo que nunca se registra suele haber fallado aquí, y aquí es donde se ve.
• Ambos entornos de ejecución de contenedores arrancaron. Container Runtime Interface for OCI (CRI-O) y Docker Application Container Engine están cada uno [ OK ], lo cual es la prueba en tiempo de arranque del comportamiento de doble entorno de ejecución que sorprende a la gente en crictl y docker.
• VP Manager image load y Argo Watch service — vpm y Argo arrancando.
• El prompt es el del propio nodo, detrás de su aviso de auditoría. La consola serie le proporciona un prompt de inicio de sesión, no una sesión.

Conectarse de forma interactiva requiere un terminal real, pero puede automatizarse

az serial-console connect pone el terminal en modo raw, por lo que no puede ejecutarse desde un pipeline ni desde ningún contexto sin TTY. Falla en el lado del cliente, antes de contactar con Azure:

ERROR: (19, 'Operation not supported by device')
  File ".../azext_serialconsole/custom.py", line 633, in connect_serialconsole
    GV.serial_console_instance.launch_console()

Ese traceback es manejo del terminal, no una caída de la consola serie.

La conexión en sí, sin embargo, es automatizable: controle el websocket directamente en lugar de la CLI. La transcripción anterior se capturó así, sin TTY. Véase scripts/serial_console_capture.py, que es la forma en que recopilaría evidencias de arranque de un nodo que no logró registrarse sin que una persona esté sentada ante un terminal.

Espere tener que reintentar: la puerta de enlace rechaza aproximadamente uno de cada dos intentos

El primer frame de la puerta de enlace es un desafío, no salida, y el cliente lo responde con un token de portador. Incluso cuando eso se hace correctamente, el socket a menudo se cierra de inmediato:

[close] code=1011 reason=Connection not trusted

Comportamiento observado: funciona de forma intermitente y, con un uso sostenido, todos los nodos del grupo de recursos lo rechazan, incluidos nodos que funcionaban minutos antes. scripts/serial_console_capture.py reintenta por defecto porque reintentar a menudo funciona.

La causa no está establecida. Lo que se ha descartado, porque cada opción es una conjetura plausible que hace perder tiempo:

No es esto	Cómo confirmarlo
Limitación (throttling) de ARM/compute	Eso devuelve HTTP 429 en las llamadas a ARM. Esto es un cierre de websocket en un canal de datos independiente.
Interceptación TLS por un proxy	openssl s_client -connect <region>.gateway.serialconsole.azure.com:443 | openssl x509 -noout -issuer. Un emisor genuino O=Microsoft Corporation lo descarta; un proveedor de proxy como emisor lo confirma, y la solución es incluir en la lista de permitidos *.serialconsole.azure.com.
Diagnósticos de arranque deshabilitados	az vm show -g <rg> -n <vm> --query diagnosticsProfile informando enabled: true.
Desajuste de token entre la concesión y el desafío	Usar un único token para ambos es la práctica correcta, pero no evita el cierre.

Lo que sí es comportamiento documentado de Azure: una sesión de consola serie por VM, y una segunda solicitud correcta expulsa a la primera. El usuario expulsado se desconecta pero no cierra sesión, así que la sesión de shell sobrevive. Dos personas depurando un mismo nodo se desplazarán mutuamente de forma repetida.

Para trabajo en volumen prefiera la API de depuración o SSH, que no tienen estos límites. SSH en particular no tiene límite de pegado ni restricción de sesión única, por lo que es la mejor opción siempre que el nodo sea alcanzable desde dentro de la VNet.

El pegado está limitado a 2.048 caracteres

Azure limita la longitud del pegado en la consola serie a 2.048 caracteres, para evitar sobrecargar el puerto serie. Enviar un comando largo — o un lote de comandos en una sola escritura — falla de una manera que se interpreta como un cuelgue o una limitación en lugar de como un límite de longitud.

Envíe los comandos de uno en uno. Esta es una restricción real para cualquier recopilación en volumen por consola serie, y otra razón para preferir la API de depuración para ese trabajo.

Lo que puede ver aquí y la API no puede mostrarle

• cloud-init ejecutándose, fallando o sin arrancar nunca: la causa habitual de un nodo que nunca se registra.
• Intentos de registración contra register.ves.volterra.io, incluido un error de configuración o un token rechazado por el tenant.
• Mensajes del kernel y del arranque de antes de que hubiera ningún agente en ejecución.
• El nodo cuando no tiene ninguna ruta de red operativa, lo que inutiliza cualquier otra vía.

Para un nodo que sí está ONLINE, prefiera la API de depuración: es automatizable, produce evidencias que puede volver a generar y no ocupa el único puerto serie.