今回は ESXi Arm Edition をインストールした Raspberry Pi 4 をシリアルコンソール化し、ヘッドレスシステムにしてみました。
ESXi のヘッドレスシステム
ESXi では昔からマウスやキーボード、ディスプレイモニター（VMware では MKS：Mouse, keyboard, Screenの略）を使わない、ヘッドレスシステムをサポートしています。このヘッドレスシステムですが、通常は特別な設定を必要とせず、条件が合致すれば自動的にヘッドレスシステムとして検出され、シリアルポートからコンソール操作ができるようになります。
ESXi のヘッドレスシステム検出時の動作
動的な通信速度の設定
ESXi では、MKS のないホストが検出されると自動的にシリアル ポートに対して COM1、115200 ボーに設定して、シリアル ポートに対してDCUI（ダイレクト コンソール ユーザー インターフェイス ）をリダイレクトします。（最終的にシリアルポートは、Port com1, Speed 115200 Baud, Data 8bit, Parity none, Stop-bit 1, Flow control none で通信をします。）この通信設定の情報の詳細は、SPCR （シリアル ポート コンソール リダイレクト）テーブルがある場合は、そこから値が読み込まれます。このデフォルト設定が無い場合、手動でパラメータを設定し、ヘッドレスとして指定することもできます。
※ESXi では速度を Baud の値が出ています。bps ではないので注意。Baud は変調の速度で、bps はデータ信号の伝送速度の単位で、実際の値は同じ場合が多いのですが、電話回線での通信のように、位相変調を使って伝送を行ったりする場合、Baud の伝送速度がbpsより高くなることがあります。
動的なモードの設定
ESXi が動的にヘッドレスモードを検出すると、シリアルポート経由で通信を始めます。このモードをシリアルポートモードと呼びます。シリアルポートモードでは、入力されてくる文字列のシーケンスに基づき、DCUI（ダイレクト コンソール ユーザー インターフェイス）、シェル、GDBまたはログの各モードで動作します。4つのモードは以下のようになっています。
- ログ モード：デバッグ ビルドのデフォルト モードで、vmkernel.log をシリアル ポートに送信
- GDB モード：デバッグ専用の場合に使用
- シェル モード：SSH のようなシェル ポート アクセス
- DCUI モード：ダイレクト コンソール ユーザー インターフェイス
シリアルポートはデフォルトで2つのポートをサポートしていて、それぞれ1つ目のcom1にはGDBとログが、com2にはDCUI（ダイレクト コンソール ユーザー インターフェイス）とシェルが出力されます。
それぞれのモードはデフォルトの設定の場合、キーボードのキーシーケンスで切り替えができます。
- ログ モード： Ctrl+G, Ctrl+B, 1
- シェル モード： Ctrl+G, Ctrl+B, 2
- DCUI モード： Ctrl+G, Ctrl+B, 3
- GDB モード： Ctrl+G, Ctrl+B, ?
操作は最初に「Ctrl+G」を押し、次に「Ctrl+B」、そして最後にモード切替の 1, 2, 3, ? をキー入力します。
ログモード Syslog に書き出していれば使わない、そしてGDBモードにしてしまうと、その後はシリアルモードに対して一切の操作ができなくなる（CLIに入ってモードを強制変更しない限り、GDBモードから抜けられない。）ので、通常はDCUIモードとシェルだけで使うと思います。
なお、間違えてGDBモードにしてしまったりしたら、CLI から以下のコマンドで復旧します。
- ログ モード： esxcfg-advcfg -s com1 /Misc/LogPort
- シェル モード： esxcfg-advcfg -s com1 /Misc/ShellPort
- DCUI モード： esxcfg-advcfg -s com1 /Misc/ConsolePort
- GDB モード： esxcfg-advcfg -s com1 /Misc/GDBPort
太字の部分を適切な値、com1 / com2 / none を指定して切り替えます。先に現在のモードを無効にして、次に新しいモードを設定します。
esxcfg-advcfg –s none /Misc/LogPort
esxcfg-advcfg –s com1 /Misc/ConsolePort
このような感じです。
ESXi 側でヘッドレスシステムを設定する
そうはいっても Raspberry Pi 4 で ESXi Arm Edition を使う場合、その小さなサイズを活用して MKS を接続しないのが普通だと思います。しかし、うまく自動的に切り替わらなくて（切り替わらなかったことは無いですが・・・・）操作できなくならないように、ESXi 側も設定変更しておきます。
ESXi に vSphere Host Client でログインし、管理=>システムに移動します。
検索窓で VMkernel.Boot.tty1Port を指定して、キーの内容を表示します。値が default なので、キーを選択しオプションの編集をクリック、下に表示されている値から該当するものを入力します。Raspberry Pi 4は UART が 0～5 まであり、シリアルポートも設定すれば複数使えるのですが、Raspberry Pi 4 デフォルトの設定では 1つだけで com1 をのみ、そして ESXi 側はログやGDBが通常使用している tty1 が、デフォルトで com1 を使っています。これを変更して VMkernel.Boot.tty1Port を com2 に変更します。（com1 を使わせないということなので、com2 以外でもよいです。）
次に、DCUI が使用する tty2 に対しては、逆にデフォルトが com2 なので、com1 に変更します。
同じように VMkernel.Boot.gdbPort を none に
VMkernel.Boot.logPort も none に変更します。
最終的に、以下の4つの値が変更されていれば、準備は完了です。初期値はデフォルト設定の際に使われる値で、それを変更するわけです。
| キー | デフォルト設定 | 初期値 | 設定値 |
| VMkernel.Boot.gdbPort | default | com1 | none |
| VMkernel.Boot.logPort | default | com1 | none |
| VMkernel.Boot.tty2Port | default | com2 | com1 |
| VMkernel.Boot.tty2Port | default | com2 | com1 |
これだけで、ヘッドレスシステム化（シリアルコンソール化）は出来上がりです。
私の場合、念のために boot 時にこの設定が反映されるよう、boot.cfgにも以下のパラメータを追加しています。
ファイルの場所：/bootbank/BOOT.CFG
修正内容： kernelopt にオプション gdbPort=none logPort=none tty2Port=com1 を追記
修正前
kernelopt=FeatureState.bnxtroce_unstable=enabled autoPartition=FALSE FeatureState.nmlx5_rdma_unstable=enabled FeatureState.bnxtnet_unstable=enabled FeatureState.ena_unstable=enabled FeatureState.nmlx5_core_unstable=enabled
修正後
kernelopt=FeatureState.bnxtroce_unstable=enabled autoPartition=FALSE FeatureState.nmlx5_rdma_unstable=enabled FeatureState.bnxtnet_unstable=enabled FeatureState.ena_unstable=enabled FeatureState.nmlx5_core_unstable=enabled gdbPort=none logPort=none tty2Port=com1
これで起動時にGDBとログを使わずに、DCUI を com1 に出せるになりました。
ヘッドレスシステム ESXi Arm Edition の画面キャプチャ
いつもの DCUI
System Customization 画面
画面表示はみんな一緒
コマンドラインシェルモード
ログイン後の画面
Raspberry Pi 4 の設定
Raspberry Pi 4 側の設定は、raspi-config コマンドを使ってシリアルポートを有効にするだけです。Raspberry Pi OS で Raspberry Pi 4 を起動し、コマンドプロンプトから
sudo raspi-config
コマンドを実行し、5 Interfacing Options=> P6 Serial でシリアルポートを有効にするだけです。これで再起動すれば Raspberry Pi 4 はシリアルコンソールが使えるようになります。
Raspberry Pi 4 からシリアルポートを取り出す
Raspberry Pi 4 では複数の 3.3V シリアルポートを GPIO ピンから取り出すことができます。そして、それぞれ別々の設定で動作させることができます。（UART0～UART5）
しかし、シリアルポートを有効にして使えるのは一つだけ、UART1 の mini UART だけです。他はごにょごにょしないと使えません。（UART0 は Bluetooth につながっています。）
UART1 は GPIO の以下のピンと接続されています。
- TXD GPIO 14 => 8番ピン
- RXD GPIO 15 => 10番ピン
詳細のピン配置は以下を参照してください。
つまり、シリアルポートとして取り出すには、この2つのピンと Grand を取り出せば OK です。
シリアルポートを取り出すアダプタは、以下のものを使いました。他にも同等の Raspberry Pi 4 で使えるものが出ているので、お気に入りのものを使うとよいと思います。
Amazon.co.jp： GAOHOURaspberry Pi ラズベリーパイ用の USB－TTLシリアルコンソールのUSB変換COMケーブルモジュールのケーブル: 家電・カメラこれはまさにダメなものでした。先日の Windows UpdateをかけてWindows 10を新しいバージョンにしたところ、早速使えなくなってしまいました。PL2303 / PL2303HX / PL2303HXA もものは、安くても買わないほう場無難です。私も買いなおしました。
ただ、このアダプタも使用しているものは PL2303HX なので、いつ使えなくなるかわかりません。できれば FTDI 対応のものを使うことをお勧めします。同じようなタイプで PL2303 のものや CH340 のものもあるのですが、それぞれ正規チップではなくてコピー品の互換チップのものが多く出回っています。互換チップだと Windows 10 などでは動作しない＆チップベンダーのドライバからもはじかれるので、チャレンジせずに動作実績のあるものを選択するのが良いと思います。正規品は Windows 10 で何もしなくても認識されます。
なお、PL2303HX などの互換チップを買ってしまった場合は、PL2303_Prolific_DriverInstaller_v1.5.0 のような古いドライバを適用すると動きます。ベンダーサポート対象外なのでリンクは載せませんが、探してみれば見つかるかもしれません。
接続はこのアダプタであれば白い線を8番ピンに、緑の線を10番ピンに、黒い線はいずれかのGrandに、そして赤い線は使いません。そして、USB 側は PC に接続するだけで使用できるようになります。
これだけで、ヘッドレスシステムの ESXi 出来上がりです。この記事では ESXi Arm Edition をヘッドレスシステム化する例として書きましたが、この内容はそのまま x86 の ESXi でも利用できます。KVM 使ってマウス、キーボード、モニターを切り替えている環境から、全てシリアルポートで管理するシンプルな構成に変えてみるのも面白いかもしれないですね。私は次にシリアル<=>Ethernet変換アダプタを使って、LAN経由でコントロールするようにしていく予定です。
おまけ
購入したけれど使っていなかった Chromebookをシリアルコンソールサーバーにしました。
/dev/ttyUSB0 ～ USBハブでシリアルコンソールケーブルをつないだ分だけ管理ができるので、これでようやく Chromebook も有効活用できそうです。
-----
[2021年1月20日：Windows Update で PL2303がだめになる部分を追記]
