墜落日記 - 2010年8月17日の墜落
VMware vSphere Hypervisor で思い付きを形にしてみたらハングアップした
先日の思い付きを形にしてみた。
ダメで元々の VMDirectPath を試してみようと思い立ったのである。
最初に VMware vSphere Hypervisor (VMware ESXi 4.1) をインストールする。
で、クライアントには VMware vSphere Client 4.1 を導入して管理する体制を整える。
VMware vSphere Client で接続してみると、VMware vSphere Hypervisor だけではろくな容量を食わないから、32GB の SSD の 24.3GB ほどがローカルストレージとして残った。
取り敢えず最近の ESXi は遊んでいないので、PCI パススルーがどのように提供されているかを確認する。
すると非常に直感的に PCI デバイスの PCI パススルーの設定があることに気付いた。
取り敢えずそれだけ確認して、ゲスト OS をインストールしてみる。
VMware ESXi 4.1 にはまだ Debian GNU/Linux Squeeze のテンプレートは無いので、"Other Linux 2.6.x kernel 64-bit" を選択してインストール。
インストールも滞りなく完了した。
この辺りは VMware Server 2.0 でも慣れ親しんでいるので非常にスムーズ。
Debian GNU/Linux Squeeze のインストールが完了したら一端終了。
3ware SAS 9750-8i と 2 つの物理 NIC を PCI パススルー指定して、3ware SAS 9750-8i を PCI デバイスとしてゲスト OS に割り当てる。
で、ゲスト OS を起動して lspci でデバイスを確認すると、3ware SAS 9750-8i が問題なく繋がっていた。
続いて lvm2 パッケージを導入して LVM を使える状態にすると、3ware SAS 9750-8i に繋がっているアレイ上に構築しっぱなしの LVM を唐突に認識、pvs や lvs などで確認できるようになった。
むむ、これはもしや、PCI パススルーに成功している！？(嬉)
あまり期待していなかっただけに、これは朗報だ。
上手く行けば VMware ESXi 4.1 で環境構築の方向性を確定できる。
しかし、もはや当然の如く問題は発生するのだ。
いい加減に糞重いリモートクライアントで作業しているのが億劫になったので外部から SSH で接続しようと、ssh パッケージをインストール。
sshd の設定をしてクライアントから SSH で接続………失敗した？
おかしい、設定は間違っていないはずだ。
取り敢えずネットワークの導通を確認しようと、ゲスト OS からクライアント側へ ping を飛ばしたら………ゲスト OS がハングアップした。
Management Network とゲスト OS のネットワークを同一にしていたせいか、VMware vSphere Client からも接続できなくなった。
VMware ESXi 自体が死んだのかと思って VMware ESXi 4.1 をインストールした実機の画面を見てみると、VMware ESXi 自体は死んでいない。
実機から直接に再起動をかけると仮想ホストは無事に再起動した。
どうも、仮想 NIC か仮想スイッチかが死んでいるのではないかと思われる。
しかし apt の設定の後に外部のリポジトリからパッケージを取得しているので、最初からネットワークが死んでいたとも考えられない。
PCI パススルーが干渉したかと思って、PCI デバイスを取り外し、PCI パススルーも解除して VMware ESXi 自体も再起動する………現象変わらず、ping でハングアップ。
こ、これは、PCI パススルー関係なくハングアップしくさっているではないくぁ！？(汗々)
VMware Tools をインストールしていないコトによる問題か？
VMware Tools がインストールされていない場合、パフォーマンス面の問題は出たとしても落ちることはないと思うのだけど？
なんにしろ PCI パススルーなんてけったいな技術も使っていないのにハングアップというのは穏やかではない。
と言うか、どうしてこう、素直にいかないのか(涙)
愚痴のひとつも言いたくなるなぁ～………(涙)
取り敢えず、色々と試してみる。
VMkernel ポートと仮想マシンポートを仮想スイッチ単位と物理 NIC 単位で完全に分離してもダメだった。
仮想マシンポートだけでなく VMkernel ポートも止まってしまった。
………って、あれ？
VMware ESXi の Management Network に割り当てた IP アドレスと、ゲスト OS の IP アドレスが衝突している………？
どうしてどっちも 172.30.100.10 なんだ？
Management Network の方は 172.30.100.20 の予定だったんだが？
もしかして、これけ？ これなのけ？
仮想マシンを起動して、クライアント側に ping を打ってみると………
だぁ～っ！！ 届いたぁ～っ！？ これかぁ～っ！？
深呼吸して、落ち着いて、自分を指差して心の声を張り上げよう。
みなさんっ！！ 馬鹿ですっ！！ 馬鹿がココにいますっ！！
くだらない、実にくだらない問題を解決できたので、再度 3ware SAS 9750-8i の PCI パススルーに挑戦してみる。
VMware vSphere Client でホスト自体を選択し、[構成]→[ハードウェア詳細設定]→[パススルーの構成...] と順に押下する。
するとパススルー可能なデバイスの一覧が出るので、01:00.0 の「3ware Inc 9750 SAS2/SATA-II RAID PCIe」をパススルーする設定にして、VMware ESXi 自体を再起動する。
再起動したら、パススルーしたデバイスを割り当てたい仮想マシンを選択し、[仮想マシンの設定の編集]を押下して設定画面を開く。
で、[追加...]を押下すると PCI デバイスが選択可能になっているので、ウィザードに従ってパススルーしたデバイスを直結する。
で、仮想マシンを起動。
ハングアップすることなく無事に起動したら lspci コマンドで認識された PCI デバイスの一覧を見てみる。
すると………
03:00.0 RAID bus controller: 3ware Inc 9750 SAS2/SATA-II RAID PCIe (rev 03)
きた、きた、きたぁ～っ！！
PCI パススルーの設定をした 3ware SAS 9750-8i がゲスト OS からしっかりと認識されていた。
続いて lvdisplay で論理ボリュームの情報を見てみる。
きた、きた、きたぁ～っ！！ きたってばよぉ～っ！！
以前に Debian GNU/Linux Squeeze を直接インストールして構成した論理ボリュームがしっかりと認識されていた。
で、気をよくしてマウントしてみると、ちゃんと中が見えた。
PCI パススルーによって仮想マシンに物理ハードディスクを認識させ、物理ハードディスクに直接構成されたパーティションテーブルや論理ボリュームを認識させることに成功した。
これで仮想マシンからの書き込みは物理ハードディスクに極小のオーバヘッドによって書き込まれるし、仮想環境の障害の際にも中身のサルベージが可能になった。
取り敢えず /etc/fstab に書き込んで再起動確認………ちゃんとマウントされた。
なんかすげぇ～嬉しい(爆)
この後 NFS を構成して NFS をストレージとして VMware ESXi に認識させ、仮想ゲストを起動するまで作業しなければ今回のプランが成功したとは言えないのだけど、今夜はもう眠い。
連日 3 時過ぎまで作業していると流石に寝落ちの危険性が出てきた。
なので、おやすみぃ～………
コメントは投稿されていません。