シリアルコンソール

2026-07-28 に、このデプロイメントの 1 台の CE から取得しました。sitecli/capture-manifest.json にどのノードかが記録されており、scripts/capture-sitecli.sh --check が稼働中の CE に対してコマンド面を再検証します。

Azure シリアルコンソールは、Azure プラットフォームを通じてノードのエミュレートされたシリアルポートに接続します。F5 Distributed Cloud のコントロールプレーン、ノードのデータプレーン、ノードが制御するネットワーク経路のいずれも経由しません。だからこそ、他のすべてが機能しないときに動作するのです。

CE が 一度も起動しなかった 場合にこれを使ってください。登録に失敗した、サイトがテナントに存在しない、あるいはノードは起動しているが外部への経路がない、といったケースです。これらのいずれの場合も、デバッグ API には中継するトンネルがありません。SSH は登録失敗後も利用できますが、それは初回ブート時に鍵が書き込まれており、かつ VNet 内部からノードの内部アドレスに到達できる場合に限られます。初めて向き合うノードでは、そのどちらも成り立ちません。

ノードに 何らかの 動作するネットワーク経路があるなら、これより先にサイトコンソールを試してください。こちらも登録失敗後に利用でき、鍵も不要で、すでにノードを見ている人を追い出すこともありません。シリアルコンソールは、壊れているのがネットワーク経路そのものである場合に残された手段です。

前提条件: ブート診断

Azure はシリアルコンソールを接続する前に、VM でブート診断が有効になっていることを要求します。これは terraform/modules/ce-node で有効化されています。

boot_diagnostics {}

空のブロックは Azure マネージドストレージを選択するため、所有・管理すべき診断ストレージアカウント、ライフサイクルポリシー、アクセスキーは存在しません。ノード上で確認します。

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

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

ブート診断は ブート時 のシリアルログを取得します。すでに実行中の VM に対して有効化しても、すでに発生済みのブートに対するログは生成されないため、 az vm boot-diagnostics get-boot-log はこう応答します。

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

これは想定どおりの動作であり、障害ではありません。ノードが次に再起動した後にブートログが存在するようになります。ただしライブのコンソール接続は即座に機能します。ログには依存しません。

ターミナルなしで可用性を確認する

接続にはインタラクティブなセッションが必要ですが、接続 できるかどうか は 2 回の API 呼び出しで分かります。どちらもヘルスチェックに有用です。

サービスはサブスクリプションに対して有効化されている必要があります。管理者はテナント全体で無効化できます。

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

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

次に、特定のノードのシリアルポートへの接続を要求します。

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"

wss:// で始まる connectionString（このデプロイメントでは eastus.gateway.serialconsole.azure.com）が返れば、コンソールは今すぐ接続可能ということです。ブート診断を有効化する前は、この呼び出しには接続先が存在しませんでした。

接続する

拡張機能を一度インストールします。
Terminal window
```
az extension add --name serial-console
```

接続します。

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

到達するのはシェルではなく、アプライアンスの監査バナーの背後にあるノード自身のログインプロンプトです。シリアルコンソールは チャネル が機能することを証明しますが、認証をバイパスするものではありません。

このデプロイメントではシリアルコンソール経由でのログインを完了した人がいないため、このページでは何を入力するかを記載しません。admin はシェルが Site CLI であるアプライアンスアカウントであり、同じアカウントがサイトコンソール経由でパスワードによって認証されます。しかし、シリアルコンソールのログインでパスワードが機能することは示されておらず、admin に対する sshd は鍵のみのため、この 2 つは明らかに同一の資格情報経路ではありません。

f5-xc-ce-vm-01 から取得したもので、systemd ユニットの出力が何も付け加えない中間部分は省略しています。

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

このトランスクリプトの中で注目に値するものが 4 つあります。デバッグ API では答えられない問いに答えてくれるからです。

cloud-init が完了した — Datasource DataSourceAzure、22.37 秒で終了。登録に至らないノードは通常ここで失敗しており、それが見えるのはこの場所です。
両方のコンテナランタイムが起動した。 Container Runtime Interface for OCI (CRI-O) と Docker Application Container Engine がそれぞれ [ OK ] になっており、これは crictl や docker で人を驚かせるデュアルランタイム動作のブート時の証拠です。
VP Manager image load と Argo Watch service — vpm と Argo の起動。
プロンプトはノード自身のもの であり、その監査バナーの背後にあります。シリアルコンソールが得られるのはログインプロンプトであって、セッションではありません。

az serial-console connect はターミナルを raw モードにするため、パイプラインや TTY のないコンテキストからは実行できません。Azure に接続する前に、クライアント側で失敗します。

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

このトレースバックはターミナル処理に関するものであり、シリアルコンソールの障害ではありません。

ただし接続自体は 自動化可能です — CLI の代わりに websocket を直接操作します。上記のトランスクリプトは TTY なしでその方法で取得しました。scripts/serial_console_capture.py を参照してください。これは、ターミナルの前に人が座らずに、登録に失敗したノードからブートの証拠を収集する方法です。

ゲートウェイの最初のフレームは出力ではなくチャレンジであり、クライアントはベアラートークンで応答します。それを正しく行っても、ソケットはしばしば即座にクローズします。

[close] code=1011 reason=Connection not trusted

観測された挙動: 断続的に成功し、継続的に使用するとリソースグループ内のすべてのノードが拒否するようになります。数分前に成功していたノードも含めてです。 scripts/serial_console_capture.py はデフォルトでリトライします。リトライすればしばしば成功するからです。

原因は特定されていません。 除外できたものは以下のとおりです。いずれも時間を無駄にするもっともらしい推測だからです。

これではない	確認方法
ARM/コンピュートのスロットリング	それは ARM 呼び出しに対して HTTP `429` を返します。これは別のデータチャネル上での websocket クローズです。
プロキシによる TLS インターセプト	`openssl s_client -connect <region>.gateway.serialconsole.azure.com:443 \| openssl x509 -noout -issuer`。正規の `O=Microsoft Corporation` 発行者ならこれは除外されます。プロキシベンダーが発行者ならこれが確定し、対処は `*.serialconsole.azure.com` の許可リスト登録です。
ブート診断が無効	`az vm show -g <rg> -n <vm> --query diagnosticsProfile` が `enabled: true` を報告していること。
付与時とチャレンジ時でのトークン不一致	両方に同じトークンを使うのが正しい方法ですが、クローズを防ぐことはできません。

一方で、ドキュメント化された Azure の挙動 は次のとおりです。VM ごとにシリアルコンソールセッションは 1 つのみで、2 番目のリクエストが成功すると 1 番目を追い出します。 追い出されたユーザーは切断されますがログアウトはされないため、シェルセッションは維持されます。1 つのノードを 2 人でデバッグすると、互いを繰り返し追い出し合うことになります。

大量の作業にはデバッグ API または SSH を選んでください。どちらにもこれらの制限はありません。特に SSH には貼り付けの上限もシングルセッション制約もないため、 VNet 内部からノードに到達できる場合は常に SSH のほうが良い選択です。

API では見せられないが、ここで見えるもの

cloud-init の実行、失敗、あるいはまったく開始されていない状態 — 登録に至らないノードの通常の原因です。
register.ves.volterra.io に対する 登録試行。設定エラーや、テナントが拒否したトークンも含みます。
どのエージェントも稼働する前の カーネルおよびブートメッセージ。
動作するネットワーク経路がない 状態のノード。これは他のあらゆる経路を無効にします。

ONLINE であるノードには、デバッグ API を選んでください。スクリプト化可能であり、再実行できる証拠を生成し、唯一のシリアルポートを占有しません。