今日の気分はバリいくつ？

Posts Tagged ‘ESXi’

自宅でサーバーとして運用しているAtomマシン（という時点で相当な変態仕様ですがw）、今までVMware ESXi 4.0で仮想マシンを3台（CentOS、Ubuntu、FreeNAS）運用していました。ESXi 4.0にはアップデート版（U1）が存在したのですが、このアップデート版をインストールすると、マシンがブルースクリーンならぬピンク？マゼンダ？のエラースクリーン表示になり、4.0に強制ロールバックされていました（このへんの作りはさすがに堅いなと思います）。

で、今回4.1へのアップデートをトライしたのですが、アップデート用のZIPファイルをダウンロードして「vSphere Host Update Utility 4.0」でアップデートを試みてもエラー表示で先に進まず。いろいろ情報を漁っていくうちに、「vSphere Host Update Utility 4.0」ではアップデート出来ないことが分かってきて、「vSphere CLI 4.1」を用いてアップデートしました。

手順はこちらを参考にさせていただきました。

VMware ESXi 4.1へアップデート。その2。 (いつか、そのとき、あの場所で。)

Atomということもあり、アップデートの手順ひとつひとつにとても時間がかかり、このまま動かなくなるのではとドキドキしましたが、無事にアップデートに成功し、うちのAtomサーバーマシンはVMware ESX 4.1で動き出しました。

以下が構成です。ESXで特に癖があるのはNICで、そこだけIntelの高級品（？）にしています。

4.0 U1ではエラーが発生して起動しなかったESXiですが、4.1は特に引っかかることもなく正常に起動。これでもうしばらく現役で使うことができそうです。

無償仮想化ソフトVMware ESXiを30分以内で使う (@IT)

VMwareから無償提供されているハイパーバイザー「VMware ESXi」のダウンロード、インストール、仮想マシンの作成までを順を追って解説した記事です。画面写真も豊富に使用されており、わかりやすくていい記事だと思いますが、手順の中に「ESXiが動くハードウェアを確保する」というのがなかったのがなんとも残念です。

というのも、VMware ESXiはハードウェアを選ぶ傾向があり、特にネットワークアダプタが対応していないと、インストールしたはいいがネットワークが使えないためリモートからアクセスできず結局何もできないという、かなりがっかりな状況になってしまうからです。私が最初にESXi 3.5を試したときにまさにこの状態になってしまい、「対応しているネットワークアダプタを買う」という強硬手段で解決しました（そのときの顛末はこのあたりをご覧ください）。

こんなこともあり、個人的にはVMware ESXiを試すのにもっとも時間のかかる工程は「ESXiが動くハードウェアを確保する」だと思っています。ここさえクリアできてしまえばあとはたいしたことはないでしょう。ハードウェアが確保できているという前提であれば、確かに30分以内でESXiを動かすことはできるかもしれませんね。

この記事は前編で、後編も予定されているようなので、後編では少しでもハードウェア選択について言及してほしいところです。

昨日（7/4）Atom自宅サーバーのVMware ESXiを3.5から4.0にバージョンアップしましたが、ESXi 3.5の時にインストールしたUbuntu9.04がESXi 4.0上でも元気に動いております（当たり前かw）。

ESXi 3.5の時は、UbuntuのGUI操作が固まる（プチフリのような感じで）現象があり、少々使いづらかったのですが、ESXi 4.0になって少し改善されたような気がします。マシン自体が非力なのでアプリの起動などはしんどいですが、メニューの操作など基本的なところは問題なしです。

自宅サーバーとして運用しているAtomマシンにはVMware ESXi 3.5をインストールしていましたが、このたびVMware ESXi 4.0をアップグレードインストールしてみました。

マシンの構成は以下のとおりです。

まずVMwareのサイトから「VMware ESXi 4.0 (upgrade ZIP)」と「VMware vSphere Client and Host Update Utility」をダウンロードします。前者がESXi 4.0のイメージファイル、後者が管理ツールのセットアップファイルです。ちなみに新規インストールする場合は、VMwareのサイトからISOイメージをダウンロードして、CDからインストールすることになります。

最初に「VMware vSphere Client and Host Update Utility」をインストールします。このとき「VMware vShere Host Update Utility」を一緒にインストールするようにオプションを選択します（デフォルトで有効になっていました）。

アップグレードするためには「VMware vSphere Host Update Utility」を起動して、ESXi 4.0のイメージファイルを指定してやります。このときESXi 3.5を稼動しているホストはメンテナンスモードにしておく必要があります。

で、アップグレード中の画面がこんな感じ。結構時間がかかるので、あせらず待ちましょう。

私の場合「アップグレードに失敗しました」というおっかないメッセージが表示されましたが、内部的にはきちんとアップグレードされていました。

アップグレード後は、インベントリ内の仮想マシンがすべてUnknownと表示されていましたが、データストアから改めてvmxファイルを指定してやることで、仮想マシンを今までどおり認識しました。仮想マシンの起動も問題なさそうです。

ちょっと使った印象としては、管理ツールが日本語対応したので非常にフレンドリーになった感じです。使い込んだらまた感想など書いてみたいと思います。

Windows 7がリリースされたらメインマシンをクリーンにして環境作り直しだなぁという思いから、メインマシンのローカルにあるデータを家庭内サーバーに移動してみました。

まず家庭内サーバーの確保から。Atomマシン上ですでに稼動しているVMware ESXi上に、新たに仮想マシンを定義してFreeNASをインストール。容量はとりあえずメインマシンのデータが収まりきればよいので、ハンドリングのことも考えて50GBに設定しました。

あとはひたすらデータをコピーしていくだけなのですが、改めてみてみるとドキュメントフォルダ内に「これ何に使ったっけ？」的なデータがあるわあるわ。私がパソコンを使い始めて以来のデータが詰まっているので、下手をすれば10年以上前のデータがあったり。将来的に使うかどうかすぐに判別できないので、疑わしきはとっておけ的に全部サーバーにコピー。こういうことするからゴミデータが増えるのですがw、データの整理はまた今度。

要するにクライアントからサーバーへのファイルコピーだけなのですが、ネットワークを介したコピーになるので結構時間がかかり1日仕事に。まあ暇がそれなりにつぶれたのでよしとします。

ESXiのバージョンアップで冷や汗 (yakibuta tech blog)

以前の記事でESXiをUpdate3にバージョンアップしてデータストアが見えなくなり、やむなくUpdate2に戻したことを書きましたが、上のブログで完璧な対策が記述されていました！ うちのAtomサーバーもこれでUpdate3に更新し、正常に動作するようになりました！ 本当に必読だと思います。

#コメントで情報をいただいたtmuraさんありがとうございます。

※トラブルの詳細は前の記事をご参照ください。

VMware ESX3.5i Update3をAtomマシン（945GCT-D）に適用したところ、SATA接続のローカルHDD上に配置されたdatastoreを認識しなかった問題ですが、

HDD増設→今までのHDDを外した状態で増設したHDDにESX3.5i Update2をインストール→今までのHDDを再び接続し、インストールしたUpdate2で起動

という手順を踏むことで、無事VMを起動することができました。ファイルもすべて無事でした。

Upgrading to ESX 3.5 Update 3 Causes Local VMFS Volume to be Unrecognized

このサポート情報を見る限り、Atomマシンの（というかICH-7接続の）SATA HDDはサポートされないということなので、今後もこの問題が解決する見込みは薄いかなと思っています。現状Update2でも不便はないので、当面はこのまま運用することにします。

#教訓：動いているマシンはいじるな

うちの自宅サーバ（945GCT-D、Atom 1.6GHz）にインストールされていたVMware ESXi 3.5をアップデートしてUpdate3にしたところ、SATAローカル接続HDD上のdatastoreを認識しなくなりました。

どうやらこれは、ICH-7のSATAに接続されたHDDがATAモードで接続されている場合に発生するようです。

Upgrading to ESX 3.5 Update 3 Causes Local VMFS Volume to be Unrecognized

※上記ページによると、ICA-7にSATAで接続したHDDはそもそもサポートされないと注記されています。今までが何となく動いていたと言うことなのでしょう。

で、うちの945GCT-DもSATAをAHCIにすれば解決…と思ったのですが、BIOSにそれらしい項目がありません。どうも945GCT-DはAHCIをサポートしないようです。

それならばと、手元にあったUpdate2のCDからブートUSBメモリを作成して、USB起動したUpdate2のESXiからデータを救出しようとしたのですが、うちの環境ではUSBメモリから起動させることができませんでした。

かくしてうちのESXiサーバーは、HDD上のdatastoreを認識せずVMが一切起動しない状態になってしまいましたorz。仕方ないので別のHDDを買ってきてそっちにUpdate2のESXiをインストールし、今のHDDからデータを救い出そうと思います。その辺の顛末はまた明日以降に。

#こういうことがあるとESXiに全幅の信頼を置けなくなってしまいますねぇ。まあサポート外の環境で使っていた方が悪いのですが。

ESXiにセキュリティアップデートが出ていたので早速適用。どうやるものかといろいろ調べてみましたが、そのものずばり「VMware Infrastructure Update」というプログラムを起動して、後は指示通りでOK。簡単ですね。この辺を参考にしました。

我が家のAtomマシンは、VMware ESXiをきちんと走らせて日々安定動作しています。一段落ついたのでパフォーマンス測定でもしてみようかと思い立ったはいいのですが、Linux用の適当なベンチマークソフトが思いつかず、とりあえずブラウザだけで実行できるJavaScriptベンチマーク「SunSpider」を実行してみました。Atomマシンでは測定対象のUbuntuのほかに、外部Webサーバ用のCentOS5.2と、内部ファイルサーバ用のFreeNASが動いている状態であることを追記しておきます。

やはり非力なAtomの上にさらにESXiをかませて、しかも背後に別の仮想マシンを2個動かしている状態なので、Atomマシンのパフォーマンスはふるいません。実際に画面を操作していても、X Windowの操作は相当にもたつき、クライアントとして使うにはストレスを感じる状態です。ただこれでもIEと比較すると早いというのが不思議w。IEはどれだけ遅いのよ？という状態です。

ちなみに同じAtomマシン上でも、VMware ToolをインストールしたWindows系OSは、Ubuntuよりもたつきが少なく、サーバー管理程度の操作ならストレスなく行えます。やはりESXiとXの相性があまりよくないのでしょう。

ただ、外部Webサーバと内部ファイルサーバの動作に関しては全く問題がないことも併せて追記しておきます。Atomの性格を考えるならば、アイドル時も低消費電力であることを生かした家庭用サーバーというのは相当適正があるように思えます。

さらにESXiの挙動として、仮想マシンにしばらく負荷がかからないとリソースの割り当てを減らし、負荷がかかるとリソースを順次増やすような動きをしているように思います。そのためWebサーバーにいきなりアクセスすると、最初のうちはレスポンスが遅いのですが次第に早くなるような感じになります。ESXiは元々エンタープライズ用途を意図しているので、限られたリソースを有効に使うためにこのような動きになっているのでしょう。

時間ができたらもう少し突っ込んでAtomのパフォーマンスについて調べてみたいと思います。