Serielle Konsole

Am 28.07.2026 von einem CE dieses Deployments erfasst. sitecli/capture-manifest.json hält fest, welcher Knoten es war, und scripts/capture-sitecli.sh --check verifiziert die Befehlsoberfläche erneut gegen ein laufendes CE.

Die Azure Serial Console verbindet sich über die Azure-Plattform mit dem emulierten seriellen Port des Knotens. Sie durchläuft weder die F5 Distributed Cloud Control Plane, noch die Data Plane des Knotens, noch irgendeinen Netzwerkpfad, den der Knoten kontrolliert — und genau deshalb funktioniert sie, wenn nichts anderes mehr geht.

Greifen Sie darauf zurück, wenn ein CE nie hochgekommen ist: die Registrierung ist fehlgeschlagen, die Site fehlt im Tenant, oder der Knoten läuft, hat aber keine Route nach außen. In all diesen Fällen hat die Debug-API keinen Tunnel, über den sie weiterleiten könnte. SSH übersteht eine fehlgeschlagene Registrierung, aber nur, wenn dessen Schlüssel bereits beim ersten Boot geschrieben wurde und Sie die interne Adresse des Knotens aus dem VNet heraus erreichen können — beides trifft auf einen Knoten, den Sie zum ersten Mal antreffen, nicht zu.

Versuchen Sie zuerst die Site Console, wenn der Knoten irgendeinen funktionierenden Netzwerkpfad hat: Sie übersteht ebenfalls eine fehlgeschlagene Registrierung, benötigt keinen Schlüssel und verdrängt nicht die Person, die den Knoten gerade betrachtet. Die serielle Konsole bleibt übrig, wenn der Netzwerkpfad genau das ist, was defekt ist.

Voraussetzung: Boot-Diagnose

Azure verlangt Boot-Diagnose auf der VM, bevor es eine serielle Konsole anbindet. Dies wird durch terraform/modules/ce-node aktiviert:

boot_diagnostics {}

Ein leerer Block wählt von Azure verwalteten Speicher, sodass es kein Diagnose-Speicherkonto, keine Lifecycle-Richtlinie und keinen Zugriffsschlüssel zu verwalten gibt. Bestätigen Sie es auf einem Knoten:

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

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

Die Aktivierung wirkt nicht rückwirkend

Die Boot-Diagnose erfasst das serielle Log beim Boot. Sie für eine VM einzuschalten, die bereits läuft, erzeugt kein Log für den Bootvorgang, der bereits stattgefunden hat, daher antwortet az vm boot-diagnostics get-boot-log:

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

Das ist erwartet, kein Fehler. Ein Boot-Log existiert, nachdem der Knoten das nächste Mal neu startet. Das direkte Anbinden der Konsole funktioniert jedoch sofort — es hängt nicht vom Log ab.

Verfügbarkeit ohne Terminal prüfen

Das Anbinden erfordert eine interaktive Sitzung, aber ob es anbinden würde, sind zwei API-Aufrufe. Beide sind in einer Health-Prüfung nützlich.

Der Dienst muss für das Abonnement aktiviert sein — ein Administrator kann ihn tenantweit deaktivieren:

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

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

Fragen Sie dann eine Verbindung zum seriellen Port eines bestimmten Knotens an:

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"

Ein connectionString, der mit wss:// beginnt — in diesem Deployment eastus.gateway.serialconsole.azure.com — bedeutet, dass die Konsole gerade jetzt anbindbar ist. Vor der Aktivierung der Boot-Diagnose hatte dieser Aufruf nichts, woran er sich anbinden konnte.

Dieser Connection String ist ein Credential

Es handelt sich um ein kurzlebiges Bearer-Token, eingebettet in eine URL. Loggen Sie es nicht, fügen Sie es nicht in ein Ticket ein und committen Sie es nicht. Geben Sie nur den Host aus, wenn Sie demonstrieren, dass der Aufruf funktioniert hat.

Anbinden

1. Installieren Sie die Erweiterung einmalig:

   az extension add --name serial-console

2. Anbinden:

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

3. Sie landen beim Login-Prompt des Knotens selbst, nicht in einer Shell, hinter dem Audit-Banner der Appliance. Die serielle Konsole beweist, dass der Kanal funktioniert; sie umgeht die Authentifizierung nicht.

   Welches Credential das serielle Login akzeptiert, ist nicht verifiziert

   Niemand hat in diesem Deployment ein Login über die serielle Konsole abgeschlossen, daher sagt diese Seite nicht, was einzugeben ist. admin ist das Appliance-Konto, dessen Shell die Site CLI ist, und dasselbe Konto authentifiziert sich über die Site Console mit einem Passwort — dass ein Passwort jedoch beim Login über die serielle Konsole funktioniert, ist nicht gezeigt worden, und sshd ist für admin ausschließlich schlüsselbasiert, sodass die beiden nachweislich nicht derselbe Credential-Pfad sind.

Erfasst von f5-xc-ce-vm-01, in der Mitte gekürzt, wo die Ausgabe der systemd-Units nichts beiträgt:

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

Vier Dinge in diesem Mitschnitt sind beachtenswert, weil sie Fragen beantworten, die die Debug-API nicht beantworten kann:

• cloud-init wurde abgeschlossen — Datasource DataSourceAzure, beendet nach 22,37 Sekunden. Ein Knoten, der sich nie registriert, ist meist hier gescheitert, und hier sehen Sie es.
• Beide Container-Runtimes wurden gestartet. Container Runtime Interface for OCI (CRI-O) und Docker Application Container Engine sind jeweils [ OK ], was der Beweis zur Bootzeit für das Dual-Runtime-Verhalten ist, das Leute bei crictl und docker überrascht.
• VP Manager image load und Argo Watch service — vpm und Argo kommen hoch.
• Der Prompt ist der des Knotens selbst, hinter seinem Audit-Banner. Die serielle Konsole verschafft Ihnen einen Login-Prompt, keine Sitzung.

Interaktives Anbinden braucht ein echtes Terminal — es lässt sich aber skripten

az serial-console connect versetzt das Terminal in den Raw-Modus, daher kann es nicht aus einer Pipeline oder einem Kontext ohne TTY laufen. Es scheitert clientseitig, noch bevor Azure kontaktiert wird:

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

Dieser Traceback ist Terminal-Handling, kein Ausfall der seriellen Konsole.

Das Anbinden selbst ist jedoch automatisierbar — steuern Sie den Websocket direkt anstelle der CLI. Der obige Mitschnitt wurde auf diese Weise erfasst, ohne TTY. Siehe scripts/serial_console_capture.py; so würden Sie Boot-Belege von einem Knoten sammeln, der sich nicht registrieren konnte, ohne dass ein Mensch an einem Terminal sitzt.

Rechnen Sie mit Wiederholungen: das Gateway verweigert etwa jeden zweiten Versuch

Der erste Frame des Gateways ist eine Challenge, keine Ausgabe, und der Client antwortet darauf mit einem Bearer-Token. Selbst wenn das korrekt gemacht wird, schließt sich der Socket häufig sofort:

[close] code=1011 reason=Connection not trusted

Beobachtetes Verhalten: Es gelingt sporadisch, und bei anhaltender Nutzung verweigert jeder Knoten in der Ressourcengruppe — einschließlich Knoten, die Minuten zuvor funktionierten. scripts/serial_console_capture.py wiederholt standardmäßig, weil Wiederholen oft funktioniert.

Die Ursache ist nicht geklärt. Was ausgeschlossen wurde, weil jede dieser Vermutungen plausibel ist und Zeit kostet:

Nicht das	Wie bestätigen
ARM-/Compute-Throttling	Das gibt HTTP 429 bei ARM-Aufrufen zurück. Hier handelt es sich um einen Websocket-Close auf einem separaten Datenkanal.
TLS-Interception durch einen Proxy	openssl s_client -connect <region>.gateway.serialconsole.azure.com:443 | openssl x509 -noout -issuer. Ein echter O=Microsoft Corporation-Issuer schließt es aus; ein Proxy-Hersteller als Issuer bestätigt es, und die Lösung ist, *.serialconsole.azure.com auf die Allow-Liste zu setzen.
Boot-Diagnose deaktiviert	az vm show -g <rg> -n <vm> --query diagnosticsProfile meldet enabled: true.
Token-Unstimmigkeit zwischen Grant und Challenge	Ein Token für beides zu verwenden ist korrekte Praxis, verhindert den Close aber nicht.

Was dokumentiertes Azure-Verhalten ist: eine serielle Konsolensitzung pro VM, und eine zweite erfolgreiche Anfrage verdrängt die erste. Der verdrängte Benutzer wird getrennt, aber nicht abgemeldet, sodass die Shell-Sitzung fortbesteht. Zwei Personen, die einen Knoten debuggen, verdrängen sich wiederholt gegenseitig.

Für Massenarbeiten bevorzugen Sie die Debug-API oder SSH, die diese Grenzen nicht haben. SSH insbesondere hat keine Einfügebeschränkung und keine Ein-Sitzungs-Restriktion, sodass es die bessere Wahl ist, sobald der Knoten aus dem VNet heraus erreichbar ist.

Einfügen ist auf 2.048 Zeichen begrenzt

Azure begrenzt die Länge des Einfügens über die serielle Konsole auf 2.048 Zeichen, um den seriellen Port nicht zu überlasten. Das Senden eines langen Befehls — oder eines Stapels von Befehlen in einem Schreibvorgang — scheitert auf eine Weise, die sich wie ein Hänger oder ein Throttle liest und nicht wie eine Längenbegrenzung.

Senden Sie Befehle einzeln. Dies ist eine echte Einschränkung für jede Massenerfassung über die serielle Konsole und ein weiterer Grund, für diese Arbeit die Debug-API zu bevorzugen.

Was Sie hier sehen können, was die API Ihnen nicht zeigen kann

• cloud-init, das läuft, scheitert oder nie startet — die üblichere Ursache für einen Knoten, der sich nie registriert.
• Registrierungsversuche gegen register.ves.volterra.io, einschließlich eines Konfigurationsfehlers oder eines Tokens, das der Tenant abgelehnt hat.
• Kernel- und Boot-Meldungen aus der Zeit, bevor irgendein Agent lief.
• Den Knoten, wenn er keinen funktionierenden Netzwerkpfad hat, was jeden anderen Weg ausschließt.

Für einen Knoten, der ONLINE ist, bevorzugen Sie die Debug-API: sie ist skriptfähig, sie erzeugt Belege, die Sie erneut erzeugen können, und sie belegt nicht den einzigen seriellen Port.