Console seriale

Acquisito il 2026-07-28 da un CE di questo deployment. sitecli/capture-manifest.json registra quale nodo, e scripts/capture-sitecli.sh --check riverifica la superficie dei comandi contro un CE attivo.

Azure Serial Console si collega alla porta seriale emulata del nodo attraverso la piattaforma Azure. Non attraversa il control plane di F5 Distributed Cloud, il data plane del nodo, né alcun percorso di rete controllato dal nodo — ed è esattamente per questo che funziona quando nient’altro funziona.

Ricorrete ad essa quando un CE non è mai partito: la registrazione è fallita, il sito è assente dal tenant, oppure il nodo è attivo ma non ha alcuna rotta verso l’esterno. In tutti questi casi l’API di debug non ha alcun tunnel attraverso cui inoltrare le richieste. SSH sopravvive a una registrazione fallita, ma solo se la sua chiave era già stata scritta al primo avvio e potete raggiungere l’indirizzo interno del nodo dall’interno della VNet — nessuna delle due condizioni è vera per un nodo che incontrate per la prima volta.

Provate Site Console prima di questa se il nodo ha qualsiasi percorso di rete funzionante: sopravvive anch’essa a una registrazione fallita, non richiede chiavi e non estromette chi è già collegato al nodo. La console seriale è ciò che resta quando è proprio il percorso di rete a essere guasto.

Prerequisito: diagnostica di avvio

Azure richiede la diagnostica di avvio sulla VM prima di collegare una console seriale. Questa viene abilitata da terraform/modules/ce-node:

boot_diagnostics {}

Un blocco vuoto seleziona lo storage gestito da Azure, quindi non c’è alcun account di storage per la diagnostica, policy di ciclo di vita o chiave di accesso da gestire. Verificatelo su un nodo:

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

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

Abilitarla non è retroattivo

La diagnostica di avvio acquisisce il log seriale all’avvio. Attivarla su una VM già in esecuzione non produce un log per l’avvio già avvenuto, quindi az vm boot-diagnostics get-boot-log risponde:

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

Questo è previsto, non è un guasto. Un log di avvio esiste dopo il successivo riavvio del nodo. Il collegamento live alla console, però, funziona immediatamente — non dipende dal log.

Verificare la disponibilità senza un terminale

Il collegamento richiede una sessione interattiva, ma sapere se si collegherebbe è questione di due chiamate API. Entrambe sono utili in un controllo di stato.

Il servizio deve essere abilitato per la sottoscrizione — un amministratore può disabilitarlo a livello di 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 } }

Poi richiedete una connessione alla porta seriale di un nodo specifico:

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"

Una connectionString che inizia con wss:// — in questo deployment eastus.gateway.serialconsole.azure.com — significa che la console è collegabile in questo momento. Prima che la diagnostica di avvio fosse abilitata, questa chiamata non aveva nulla a cui collegarsi.

Quella stringa di connessione è una credenziale

È un bearer token di breve durata incorporato in un URL. Non registratelo nei log, non incollatelo in un ticket, non committatelo. Stampate solo l’host quando dimostrate che la chiamata ha funzionato.

Collegamento

1. Installate l’estensione una sola volta:

   az extension add --name serial-console

2. Collegatevi:

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

3. Arrivate al prompt di login del nodo stesso, non a una shell, dietro il banner di audit dell’appliance. La console seriale dimostra che il canale funziona; non aggira l’autenticazione.

   Quale credenziale accetti il login seriale non è verificato

   Nessuno ha completato un login tramite console seriale su questo deployment, quindi questa pagina non indica cosa digitare. admin è l’account dell’appliance la cui shell è la Site CLI, e lo stesso account si autentica tramite Site Console con una password — ma non è stato dimostrato che una password funzioni con il login della console seriale, e sshd accetta solo chiavi per admin, quindi i due percorsi di credenziali sono dimostrabilmente diversi.

Acquisito da f5-xc-ce-vm-01, con omissioni nella parte centrale dove l’output delle unit systemd non aggiunge nulla:

+-----------------------------------------------+
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

In quella trascrizione ci sono quattro elementi degni di nota, perché rispondono a domande a cui l’API di debug non può rispondere:

• cloud-init completato — Datasource DataSourceAzure, terminato a 22,37 secondi. Un nodo che non si registra mai di solito è fallito qui, ed è qui che lo vedete.
• Entrambi i runtime di container sono partiti. Container Runtime Interface for OCI (CRI-O) e Docker Application Container Engine sono entrambi [ OK ], che è la prova al momento dell’avvio del comportamento dual-runtime che sorprende gli utenti in crictl e docker.
• VP Manager image load e Argo Watch service — vpm e Argo che si avviano.
• Il prompt è quello del nodo stesso, dietro il suo banner di audit. La console seriale vi porta a un prompt di login, non a una sessione.

Il collegamento interattivo richiede un terminale reale — ma può essere automatizzato

az serial-console connect mette il terminale in modalità raw, quindi non può essere eseguito da una pipeline o da qualsiasi contesto senza una TTY. Fallisce lato client, prima di contattare Azure:

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

Quel traceback riguarda la gestione del terminale, non un’interruzione della console seriale.

Il collegamento in sé, però, è automatizzabile — pilotate direttamente il websocket invece della CLI. La trascrizione sopra è stata acquisita così, senza TTY. Vedete scripts/serial_console_capture.py, che è il modo in cui raccogliereste evidenze di avvio da un nodo che non è riuscito a registrarsi senza una persona seduta a un terminale.

Aspettatevi di dover riprovare: il gateway rifiuta circa un tentativo su due

Il primo frame del gateway è una challenge, non output, e il client risponde con un bearer token. Anche quando questo viene fatto correttamente il socket spesso si chiude immediatamente:

[close] code=1011 reason=Connection not trusted

Comportamento osservato: riesce in modo intermittente, e sotto uso prolungato ogni nodo del gruppo di risorse rifiuta — inclusi nodi che funzionavano pochi minuti prima. scripts/serial_console_capture.py riprova per impostazione predefinita perché riprovare spesso funziona.

La causa non è accertata. Ciò che è stato escluso, perché ognuna di queste è un’ipotesi plausibile che fa perdere tempo:

Non è questo	Come confermarlo
Throttling di ARM/compute	Quello restituisce HTTP 429 sulle chiamate ARM. Questa è una chiusura di websocket su un canale dati separato.
Intercettazione TLS da parte di un proxy	openssl s_client -connect <region>.gateway.serialconsole.azure.com:443 | openssl x509 -noout -issuer. Un issuer autentico O=Microsoft Corporation lo esclude; un vendor di proxy come issuer lo conferma, e la soluzione è inserire *.serialconsole.azure.com in allow-list.
Diagnostica di avvio disabilitata	az vm show -g <rg> -n <vm> --query diagnosticsProfile che riporta enabled: true.
Mancata corrispondenza del token tra grant e challenge	Usare un solo token per entrambi è la pratica corretta, ma non impedisce la chiusura.

Ciò che è comportamento documentato di Azure: una sola sessione di console seriale per VM, e una seconda richiesta riuscita estromette la prima. L’utente estromesso viene disconnesso ma non fatto uscire, quindi la sessione di shell sopravvive. Due persone che effettuano il debug di uno stesso nodo si sposteranno a vicenda ripetutamente.

Per il lavoro in blocco preferite l’API di debug o SSH, nessuno dei quali ha questi limiti. SSH in particolare non ha limite di incollaggio né restrizione a una singola sessione, quindi è la scelta migliore ogni volta che il nodo è raggiungibile dall’interno della VNet.

L'incollaggio è limitato a 2.048 caratteri

Azure limita la lunghezza dell’incollaggio nella console seriale a 2.048 caratteri, per evitare di sovraccaricare la porta seriale. Inviare un comando lungo — o un batch di comandi in un’unica scrittura — fallisce in un modo che sembra un blocco o un throttling anziché un limite di lunghezza.

Inviate i comandi uno alla volta. Questo è un vincolo reale per qualsiasi raccolta in blocco tramite console seriale, e un ulteriore motivo per preferire l’API di debug per quel lavoro.

Cosa potete vedere qui che l’API non può mostrarvi

• cloud-init in esecuzione, in errore, o che non parte mai — la causa consueta di un nodo che non si registra mai.
• Tentativi di registrazione verso register.ves.volterra.io, incluso un errore di configurazione o un token rifiutato dal tenant.
• Messaggi del kernel e di avvio da prima che qualsiasi agent fosse in esecuzione.
• Il nodo quando non ha alcun percorso di rete funzionante, situazione che rende inutilizzabile ogni altra via.

Per un nodo che è ONLINE, preferite l’API di debug: è automatizzabile, produce evidenze che potete rieseguire e non occupa l’unica porta seriale.