墜落日記 - 2010年8月15日の墜落
VMware Server 2.0 の不安定現象に関する考察
Debian GNU/Linux Squeeze に無理矢理入れた VMware Server 2.0 がカーネルも変えていないのに原因不明の vmware-config.pl の再実行を要求してくる現象に関して。
どうも色々とからかってみると、仮想マシンを起動してから停止した後に、vmnet カーネルモジュールが正常にリムーブできていないことが問題のような気がしてきた。
VMware Server 2.0 はカーネルモジュールとして vmnet、vmci、vmmon、vsock の４つをロードする仕様のようだ。
で、OS 起動後に仮想マシンを一度も起動していない場合、
/etc/init.d/vmware stop
でデーモンを停止させるとこれらは正常にリムーブされる。
しかし仮想マシンを一度でも起動／停止してから同様にデーモンを停止させようとすると、Virtual ethernet サービスの停止に失敗し、vmnet カーネルモジュールのみ参照数 1 で残留する。
このまま今度は、
/etc/init.d/vmware start
でデーモンを起動すると、vmnet カーネルモジュールの参照数は残留した参照数と合わせて最初の 13 から 14 に増えてしまう。
ここで更にデーモンを停止させると、Virtual ethernet サービスに加えて今度は自動実行の仮想マシンを制御するらしい Virtual machines と VMware Server Host Agent の停止に失敗する。
ps でプロセスを見てみると、vmware-watchdog と webAccess が順当に残っている。
この状態で更にデーモンを起動しようとすると、vmware-config.pl の再実行を要求してくる様だ。
ここから推論するに、vmnet カーネルモジュールを中心に問題が起こっているっぽい。
ここで vmware-config.pl を実行してもサービスが停止できないために怒られる。
仕方ないので、vmware-watchdog と webAccess を順番に殺し、vmnet カーネルモジュールを強制的にリムーブする。
ここで vmnet カーネルモジュールには参照数があるので rmmod に -f オプションを付けないとリムーブできないことに注意。
再度 vmware-config.pl を実行するとカーネルモジュールがビルドされて、目出度く VMware Server 2.0 が再起動する。
ここで仮想マシンを起動せずにデーモンの上げ下げを繰り返しても現象は出ない。
やはり vmnet カーネルモジュールが正常にリムーブできないのが問題のようだ。
なるほど、これならストレージ容量の再認識のためだけに VMware Server 2.0 を再起動してしまって問題が起こった現象に一致する。
vmnet カーネルモジュールが正常にリムーブされない現象は自分の拙い Linux 知識では調査しきれないけど、少なくとも確実に現象を出せる様になった。
つまり確実に現象が出せる事象を回避すればよいわけだが………実運用に入ったら仮想マシンの上げ下げならまだしも、VMware Server 2.0 の上げ下げなんか連発しないなぁ～(汗々)
実は問題ないのかもしれん………(汗々)
あと、Windows XP Mode 上の Internet Explorer 6.0 から VMware Virtual Infrastructure Web Access を利用すると悲しいほどにトラブル無しで利用できることが判明した。
先日の日記へのコメントに面白い提案があった。
こちらの記事であるが、Xen だと PCI パススルーが使えるので、ストレージコントローラ（記事では SATA コントローラ）を PCI パススルーで特定の domU に割り当ててしまう方法だ。
そもそもの問題を考えてみる。
- 今回の仮想化の中で、開発環境も仮想化したい
- 開発環境はディスク I/O が重いので SAN では帯域不足で効率が悪い
- 結果として開発環境の仮想マシンはストレージサーバと同居する
- ストレージサーバ自体を仮想ホストとすると、ストレージ管理は仮想ホストに依存し、外部の仮想ホストへの iSCSI や NFS のエクスポート、CIFS のファイルサーバ機能などは仮想マシンが担うことになる
- ストレージサーバのハードウェアに障害があった場合、CIFS で公開されていたファイル群は仮想化されたハードディスクイメージの中となるのでサルベージするまでがとても遠い
- XenServer の dom0 をファイルサーバとして利用する手もあるが、XenServer のバージョンアップの度にファイルサーバを構築し治すのはナンセンス極まる
ここで XenServer の PCI パススルーを利用する事を前提に考えると、こうなる。
- ストレージサーバにまず XenServer をインストール
- XenServer で 3ware SAS 9750-8i は PCI パススルーし、domU に割り当てる
- domU では 3ware SAS 9750-8i に繋がっているアレイに Debian インストールする
- domU にインストールした Debian でファイルサーバ機能を構築する
- domU の Debian から iSCSI や NFS をエクスポートし、その他の domU のストレージを格納する
- その他の domU に構築された仮想マシンのストレージは、iSCSI や NFS だとしても同一ホスト上のネットワークであり、多分帯域が充分に稼げる
dom0 が認識するネットワークストレージを dom0 が管理する domU がエクスポートしているという鶏と卵みたいな関係になってしまうが、これは全ての問題を満足する手法かもしれない。
ストレージサーバのハードウェアに障害があった場合でも、ハードディスクが PCI パススルーで直接的に制御されているのであれば別のマシンにつなぎ替えて中身を取り出すのもそう難しい話ではないだろうし、場合によっては XenServer の層を無くしてしまって domU を物理サーバとして直接起動するなんてことも出来るかもしれない。
しかも全ての開発環境、外向けサーバ群が XenCenter で一括管理できる。
問題は SAN に繋がるネットワークが domU から見ると通常のネットワークで、dom0 から見るとストレージネットワークにして通常のネットワークというところか。
こちらの記事で実際に構築できているので可能なのかと思うが、通常のネットワークとストレージネットワークが同一というのは、DMZ に置くような外向きの仮想ホストではセキュリティ的に危なっかしくて使えないな手段だね(汗々)
（仮想マシンが乗っ取られたらストレージネットワークが丸見え）
内側にあるストレージサーバだからこそ出来る荒技か。
あとはファイルサーバとして構築された domU は、仮想マシンにもかかわらずハードウェアと密結合になるので移動できないという問題が発生するが、もともとストレージサーバは物理環境として構築しようとしていたわけだから、これを問題と認識する必要はない。
ただ、ざっと見渡したところ、XenServer の 5.5 日本語マニュアル、5.6 英語マニュアルに PCI パススルーの記述は見当たらない。
試してみるとすれば、もとになった Xen の情報を調査するしかあるまいな………
コメントは投稿されていません。