目次
ざっくり紹介
いろいろあって作りました。
これを使うと、vSphere 環境上の仮想マシンを、IPMI （ipmitool など）で制御できます。
物理サーバとまったく同じプロトコルが（もちろん全部ではないですが）仮想マシンに対して使えるようになるため、単に ipmitool による手動操作だけでなく、バックエンドで IPMI を必要とする、または IPMI があれば動かせる物理サーバ向け機能も仮想環境で動作させられる 可能性がある点が大きなメリットです。
具体的には、
ipmitoolでの手動操作（電源制御、起動デバイスの変更）- vCenter Server からの ESXi のパワーオン
- vSphere DPM（Distributed Power Management）による自動電源制御
- oVirt など他の仮想環境管理ツールの自動電源制御
- OpenShift の Baremetal IPI など、物理サーバに対する自動プロビジョニング機構
が、vSphere の仮想環境内で実際に動作させられる可能性があります。
もちろん、物理環境を完全にエミュレートできるわけではないため、完全な代替とは言えず種々の注意は要しますが、前述のものはいずれも動作確認済みです。
本エントリでは、仕組みと簡単な使い方を紹介します。
仕組み
OpenStack 傘下のプロジェクトで、IPMI で libvirt 管理下の KVM 仮想マシンを制御できる VirtualBMC というものがあり、今回の VirtualBMC for vSphere は、それの libvirt 部分を vSphere 向けに修正したうえで機能追加したものです。
よって、仕組みは前身の VirtualBMC に準拠したものですが、とはいえごく単純（というかこれ以外にないともいう）で、IPMI コマンドを外部から受け付けるデーモンが、受け付けたコマンドと同等の処理を vCenter Server に API でリクエストしなおすだけです。
なお、IPMI の世界では、コマンドを受け付けた BMC と操作対象の物理サーバは一対一である前提なので、プロトコルレベルでは操作対象を指定する仕組みをそもそも持っていません。すなわち、操作対象の仮想マシンは、物理サーバの IPMI 操作と同様に、IPMI の投げ先の IP アドレスとポート番号で厳密に指定できる必要があります。
このため、VirtualBMC では、操作対象の仮想マシンごとに別の仮想 BMC インスタンスを同時に起動できるようになっていて、かつそのインスタンスはインスタンスごとにホストの任意の IP アドレスや任意のポートにバインドできるようになっています。
簡単な使い方
詳しくは別で書いてあるので併せてどうぞ。
セットアップ
Python 3.x と pip が動く環境で pip install vbmc4vsphere するとインストールできます。
$ python -m pip install vbmc4vsphere
インストールしたら、まずはデーモンを起動します。バックグラウンドで起動させる場合はオプション無し、フォアグラウンドで動かして出力（ログ）を見たい場合は --foreground を付けます。
$ vsbmcd --foreground
その後、vsbmc add で新しい仮想 BMC を作成します。この時に、仮想マシン名や待ち受ける IP アドレス（--address）とポート番号（--port）、vCenter Server の認証情報などを突っ込みます。
$ vsbmc add lab-vesxi01 --port 6230 --viserver 192.168.0.1 --viserver-username vsbmc@vsphere.local --viserver-password my-secure-password
制御したい仮想マシンの数だけこれを繰り返します。上記の例ではポート番号だけを指定していて、その場合はホストのすべての IP アドレス（0.0.0.0）で待ち受けるように設定されます。
なお、ポート番号として 1024 以下を指定したときは、デーモンを管理者権限（sudo するか root ユーザ）で起動していないと、この後の起動でコケるので注意です。
作成できたら、仮想 BMC を起動させます。
$ vsbmc start lab-vesxi01
登録情報や状態は、vsbmc list や vsbmc show で確認できます。
$ vsbmc list
+-------------+---------+---------+------+
| VM name | Status | Address | Port |
+-------------+---------+---------+------+
| lab-vesxi01 | running | :: | 6230 |
+-------------+---------+---------+------+
$ vsbmc show lab-vesxi01
+-------------------+---------------------+
| Property | Value |
+-------------------+---------------------+
| active | False |
| address | :: |
| password | *** |
| port | 6230 |
| status | running |
| username | admin |
| viserver | 192.168.0.1 |
| viserver_password | *** |
| viserver_username | vsbmc@vsphere.local |
| vm_name | lab-vesxi01 |
+-------------------+---------------------+
止めるときは vsbmc stop です。
$ vsbmc stop lab-vesxi01
動作確認
vsbmc start して状態が running になったら、IPMI コマンドでの操作ができるようになるはずです。
ユーザ名とパスワードはデフォルトでは admin、password です。変更したい場合は、先の vsbmc add するときの引数で指定できます（vsbmc add --help でヘルプ参照）。
$ ipmitool -I lanplus -H 192.168.0.100 -p 6230 -U admin -P password chassis power on
Chassis Power Control: Up/On
$ ipmitool -I lanplus -H 192.168.0.100 -p 6230 -U admin -P password chassis power status
Chassis Power is on
$ ipmitool -I lanplus -H 192.168.0.100 -p 6230 -U admin -P password chassis power soft
Chassis Power Control: Soft
$ ipmitool -I lanplus -H 192.168.0.100 -p 6231 -U admin -P password chassis power reset
Chassis Power Control: Reset
$ ipmitool -I lanplus -H 192.168.0.100 -p 6231 -U admin -P password chassis bootdev pxe
Set Boot Device to pxe
$ ipmitool -I lanplus -H 192.168.0.100 -p 6231 -U admin -P password chassis bootparam get 5
Boot parameter version: 1
Boot parameter 5 is valid/unlocked
Boot parameter data: 8004000000
Boot Flags :
- Boot Flag Valid
- Options apply to only next boot
- BIOS PC Compatible (legacy) boot
- Boot Device Selector : Force PXE
- Console Redirection control : System Default
- BIOS verbosity : Console redirection occurs per BIOS configuration setting (default)
- BIOS Mux Control Override : BIOS uses recommended setting of the mux at the end of POST
コンテナ環境で動作させる場合
コンテナでも動作することは確認できていて、使い方は Wiki に書いてあります。
コンテナイメージも Docker Compose 用のファイルも用意済みなので、慣れている方はこちらの方が環境を汚さないし良いでしょう。ポートのバインドがデーモンレベルとコンテナレベルの二か所で必要になってちょっと複雑なので、そこだけ注意です。
利用上の注意
根本的には、本番利用は当然想定していないので、テストとか遊びとか、そういう感じで使ってください。
また、vsbmc add で指定したときの情報は、~/.vsbmc/<仮想マシン名>/config に 平文で 保存されます。これには vCenter Server のパスワードも含む ため、運用には注意が必要です。
ユースケース
試したいくつかの使い方を紹介します。
ネステッド ESXi のパワーオン
VirtualBMC for vSphere は、vCenter Server に ESXi の BMC として登録できます。
このため、ネステッド ESXi の BMC として VirtualBMC for vSphere を登録する と、物理 ESXi と同じように、ESXi のパワーオン（スタンバイからの復帰）が vSphere Client から行える ようになります。
vCenter Server へ登録する BMC は、待ち受けポートが必ず 623 番でなくてはならず、また、誤登録防止のために MAC アドレスも必要です。これらを考慮したガイドを Wiki に載せています。
ネステッド環境で vSphere DPM を有効化
前述のように、VirtualBMC for vSphere はネステッド ESXi の BMC として登録できるので、つまり、ネステッド ESXi で構成されたホストクラスタで、DPM（Distrubuted Power Management）も有効化できます。
vSphere DPM は、これまで物理サーバなしには試すのが難しかったのですが、これで比較的簡単に動かせるようになります。
上のアニメーションは、ネステッド ESXi で構成されたホストクラスタで vSphere DPM を有効化した結果、
- ESXi のスタンバイからの自動的な復帰
- 復帰後の自動負荷平準化（vMotion）
が動作している様子です。同様に、動作している仮想マシンを減らすと、ESXi が自動的にスタンバイモードに移行する様子も観察できます。
なお、vSphere DPM をネステッド環境で動作させる上では、vSphere DPM のコスト計算が正しくない 点に注意が必要です。
vSphere DPM は、ESXi のスタンバイ化やパワーオンの必要性を評価するためにさまざまなメトリックを利用しており、それには ESXi 自身が自分自身のハードウェアから直接取得する情報 が含まれます。
しかしながら、ネステッド ESXi が使っている 仮想ハードウェアは、それらの情報を提供しません。例えば、ネステッド ESXi の消費電力は常にゼロとして評価されます。そして、ハードウェアから直接でしか情報を取得しないので、そこに 仮想 BMC が介在する余地はありません。
結果として、vSphere DPM のコストの評価結果が正しくなく、期待した推奨が提案されない 場合があります。本気の検証には向かないので、あくまで動作の雰囲気をつかめるくらいと捉えるのがよいでしょう。
構成方法は、前述のガイドに載せています。
oVirt でネステッド KVM のフェンスエージェントとして登録
oVirt では、ノードの BMC をフェンスエージェントとして登録すると、可用性の向上が実現できます。具体的には、ホストで障害が検出されると、スプリットブレインの発生有無の確認のためにホストの電源状態を確認したり、電源がオフであることが分かった場合には電源の投入などが試みられます。
VirtualBMC for vSphere は、vSphere 環境の仮想マシンとして構成した KVM ホストの BMC として oVirt に登録できます。
構成方法は、Wiki に載せています。
OpenShift の自動ベアメタルインストール（IPI）を仮想マシンで
OpenShift をまっさらな環境にほぼ全自動でインストールする方法に IPI と呼ばれる手段があり、そのうち まっさらな物理サーバに全自動でインストールする方法が、ベアメタル IPI（Baremetal IPI）です。
名前の通り、本来は物理的に BMC を積んだベアメタルサーバ（物理サーバ）に対して自動インストールを行うもので、その過程では IPMI での電源制御やブートデバイス指定（PXE、ローカルディスクなど）が駆使されます。
VirtualBMC for vSphere を使うと、これを仮想マシンに対して行えるようになります。
上の画像は、実際に仮想マシンに対してベアメタル IPI の手順で構成した OpenShift 環境です。実体は仮想マシンですが、OpenShift としては Bare Metal Hosts として登録されています。Management Address に表示されている先が、VirtualBMC for vSphere です。
もちろん、OpenShift としてはそもそも vSphere 環境向けのインストール手段も用意されているので、OpenShift 環境が欲しいだけならそれでもよいわけですが、どちらかというとこのユースケースは 物理サーバのプロビジョニング手順を仮想環境で気軽に試せる ことがメリットかと思います。
サンプルの設定例などは Wiki に載せています。
余談： 開発のきっかけ
もともとは vSphere DPM がどうのこうのなどはまったく考えておらず、oVirt を動かして遊びたくなっただけでした。
その時は、ネステッド ESXi と同じく、vSphere の上にネステッド KVM として組めばいいやと考えたわけですが、ドキュメントを読んでいたところこんな記述を見つけました。
Power management must be configured for the hosts running the highly available virtual machines.
Administration Tasks | oVirt
可用性を高くしたいなら電源管理を構成にしなさいよ、とのことです。しなくても HA 自体は機能するようですが、こうなるとせっかくなので試したくなるわけです。
電源管理というのは、oVirt 的には フェンスエージェントを構成して oVirt がホストの電源状態を確認・制御できるようにすること を意味します。これにはつまり何らかの BMC が必要です。
エージェントに ipmilan が選べるので、IPMI が喋れさえすればよさそうですが、そもそもネステッドで組もうとしているので、vCenter Server にも ESXi にも仮想マシンの IPMI 操作を受け付ける機能はないし、どう考えても無理です。
とはいえ、IPMI over LAN なんてただの UDP パケットなわけだし、世の中のだれかが仮想 IPMI ゲートウェイ的なものをすでに作っていることはじゅうぶんに期待できます。が、調べると、残念ながら vSphere 向けは皆無でした。
先行事例は、以下のような具合です。
- pyghmi
- OpenStack 傘下の Python 製サーバ管理用モジュール
- IPMI のサーバ側としての初期ネゴシエーション、セッション管理の仕組みや、物理サーバの BMC をエミュレートするクラスが実装済み
- VirtualBMC
- OpenStack 傘下の仮想 BMC
- IPMI コマンドを受けて
libvirtドライバ経由で仮想マシンを制御できる pyghmiをベースにしている
- mushorg/conpot
- 産業用の監視・制御・データ収集システム向けのハニーポット
- IPMI も受け付けてフェイクの返事を返すようにできている
pyghmiをベースにしている
- rhtyd/ipmisim
- 上記
conpotから IPMI 部分だけを切り出した IPMI のシミュレータ
- 上記
調べた範囲では VirtualBMC がいちばんぼくの求めるモノに近く、libvirt 向けの処理を pyvmomi で vSphere 向けに書き直せばどうにかなりそうだったので、ライセンスも APL 2.0 ですし、これを基に拡張していこうというのが今回の開発のきっかけでした。
VirtualBMC ですでに書かれていた処理を vSphere 向けに置き換えるところまではさくさくだったのですが、vSphere DPM での利用を目論んで vCenter Server に BMC として登録できるようにする部分が厄介でした。
結局、VirtualBMC（やその基の pyghmi）でも対応していないパケットのフォーマットや IPMI のコマンドがいくつも必要になってしまい、それらを処理する部分を完全に自製することになりました。
パケットをキャプチャして、IPMI と ASF の仕様書を片手に vCenter Server からの要求を読み解き、応答パケットを仕様書に従って組み立てて投げる、的な作業の繰り返しです。
すごくおもしろかったです。
本エントリ執筆時点で、累計ダウンロード数がすでに 1,300 を超えており、ニッチながらそこそこの需要はあったのかもしれない感触を得られています。ご活用ください。
追記： バージョン 0.1.0 で、コマンド名を vsbmcd と vsbmc に変更しました。これまでフォーク元の本家 VirtualBMC からコマンド名を変えておらず実は競合する状態を放置したままでしたが、これを解消させる目的です。併せて、本文中のコマンドも修正しました。
