ちなみに、ubuntu/debianどちらもPVにできたんですが、以下の点で苦労しました。トライする人はご注意ください。

• pygrubはgrub2形式の設定ファイルを取り扱うことができません。ubuntu9.10はgrub2が入るのでgrub-pcへ入れ替えなければPV後起動できなくなります。
• /bootパーティションは論理パーティションに置かなければなりません。ubuntuデフォルトでは拡張パーティションに/bootが作られるので、PV化すると起動しなくなります。
• HVM/PVどちらでも動くようにするためには、それぞれに対応したカーネルをインストールし、grubのroot=の箇所はUUIDで書くとどちらでもうまく扱ってくれると思います(おぼろげ)。
• 起動しなくなったら、ホストからxe-edit-bootloader コマンドでVMのfstabが編集できる。ただし、論理パーティションに/bootがある場合のみにしか使用できない。
• xe vm-param-set uuid=<VM UUID> PV-args=”console=tty0 xencons=tty” のPV-argsは使用するカーネルによって違う。citrixのforum等ではconsole=hvc0にするよう書いてあったが、自分の場合はnoninteractive(CentOSと一緒)でコンソールが使えた。tty0やhvc0では逆にコンソールが使えなかった。

容量が結構あるので、サーバには置きませんがubuntu9.10、debian lennyのXenServerテンプレート(amd64)欲しいかたいたらtwitter:artnまでご連絡ください。おすそ分けします。

先に何が起こるかというと、bnx2のドライバの問題によりjumbo frameの設定をしているNICがBroadcom製の場合、ifup/ifdownやrmmodでkernel panicが発生しXenServerホストの再起動が発生します。Redhat ELにも存在しているバグのようです。
仮想化していない状態であれば、1台のサーバが落ちる程度(というカジュアルな場合だけでもないのですが)ですし、ifup/ifdown/rmmodなどは大抵行われないオペレーションなのでそれほど目立った問題にはなっていないようです。

ところが、XenServerでは話が全く変わってきます。
XenServerは複数の物理サーバを「リソースプール」として纏める機能があるのですが、これが問題になります。XenServerはXapiというapiで複数の物理サーバを纏めて管理する事ができます。物理サーバの中で1台が「プールマスタ」として全ての物理サーバに対してのオペレーションを引き受けるapiを提供するのですが、プールマスタといえども所詮は Linux。メンテナンスで再起動の必要も出てきます。その際にはプールマスタとしての役割を別の物理サーバへ移す訳ですが、管理上の制約なのかこの時インターフェースの再設定が全ての物理サーバで行われます。そこでifdown/ifupなどのコマンドが使用され、kernel panicを起こすのです。かといって、リソースプール内でiscsiのストレージを使用するとなると、jumbo frameは必須で気軽にはずすわけにも行きません。
わかりにくいかもしれませんが、纏めると以下の2点の現象が発生します。。

1. bnx2なXenServer5.5ではifdown/ifup/rmmodなどの操作でkernel panicが発生、再起動が発生する
2. XenServerは物理サーバを纏めて管理する「リソースプール」という機能があり、「プールマスタ」の変更では全ての物理サーバに置いてネットワークインターフェースの再起動が発生する

に集約されます。勘の良い人はお分かりかもしれませんが、この２点から以下のような事象が発生するわけです。

セキュリティアップデート等でプールマスタの変更を行うと、リソースプール内のBroadcom製のNICを使用しているサーバが全てkernel panicを起こし、再起動する。

10台の物理サーバで各サーバに5台の仮想サーバを稼働させていたとすると、同時に50台の(仮想)サーバが落ちるって事です。幸い該当のプール上の仮想サーバは開発用だったりで、甚大な被害はありませんでしたが、サーバ管理者からするとクラウドなんて糞食らえって事になりますよね。該当してしまった不幸な管理者の方、どうしたらいいのって話に鳴ると思うのですが、Linuxベースのプロダクトということで、ドライバを更新すれば解決できます。サポートの問題は残りますが、解決方法をCitrixのフォーラムにポストしました。

つか、Citrix開催のXenServerのセミナーでエンジニアの人にこの件で話をしたんですが問題の重大性を理解してもらえず、「そんなの知らない、情報が欲しければサポート契約してね」みたいな感じで、問題意識の共有ができなかったのが残念です。ヘビーユースの予定だったのでサポート契約もかなり前向きに検討していたのですが、一気にモチベーション下がりました。

という残念な〆ですみません。まとめると、broadcomなNICをXenServerで使用するときはXenServer付属のドライバではなく、Broadcom製や各ベンダー配布のドライバに更新してから使えってことです。ちなみに、XenServer5.5 update1でもこの問題は解決していないので、update1インストール後もドライバの更新が必要になります。

対象のホスト名をxs01、対象のインターフェース(pif)をeth1のmtuを9000に変更するには以下の手順で行います。多分XenCenterからは出来ません。XenCenterってXenServerの持つ機能のうち、メジャーな部分しか弄れないんですよね。

1. xe pif-listを使用して、該当のpifのUUIDを取得します。
2. 取得したuuidに対して、xe pif-param-set で値を設定します。

具体的には以下のような感じです。

$ xe pif-list host-name-label=xs01 device=eth1
uuid ( RO)                  : 27bc25eb-4b48-68c7-4b90-a4f10d61eaa2
                device ( RO): eth1
    currently-attached ( RO): true
                  VLAN ( RO): -1
          network-uuid ( RO): 5bd5aebd-1ad6-4dfb-3ff3-1b8f2df44a91

$ xe pif-param-set uuid=27bc25eb-4b48-68c7-4b90-a4f10d61eaa2 other-config:mtu=9000

とする事で、次回のOS再起動時にmtuの値が反映されます。再起動時しないでもできるようなのですが、mtuの値なんて初期インストール時にしか設定しないでしょうし、初期インストール時なら再起動も容易でしょうから、今回は深追いせず再起動で対処しました。

まずは前回に引き続き各仮想化エンジンの印象とか。1エントリで載せようかと思ったのですが、思った以上に長くなってしまったので今回はOSSなXenについて記載して、その他のプロダクトは次回以降に載せます。OSSなXenしか書いてないのに長文ですみません。

- OSS Xen

以降の印象はかなりネガティブな記載が多いかもしれませんが、実は一番使っています。サーバを仮想化する事だけに関しては全く文句ないくらい安定しています。ただし、他の商用ベンダーの出しているプロダクトに比べると、著しく運用効率が悪いだけで純粋に仮想化エンジン自体に対してネガティブな訳ではありません。また、Xenから派生しているプロジェクトに関してはキャッチアップができなおらず、結果として的外れな指摘をしているかもしれません。その際はコメントやトラックバックを頂けると幸いです。

ざっくりとした印象で言うと3年前はブレイクの気配があったのですがCitrixに買収された結果、OSS陣営から見放され骨抜きになった感が否めない感じです。Redhat EL5では製品の寿命まではサポートされるので、ある意味運命共同体であるCentOS5が使われている限りなくなる事はないでしょう。Redhat EL6/CentOS6が出るあたりが山場でしょうね。その頃には仮想化エンジン間での移行の体制も業界的にできているでしょうし、その際にOSSなXenを選ぶメリットをどれだけ提供できるのか、先は明るくないように思えます。KVMもOSSなXenだったら後ろ姿が見えてきた事でしょうし。

機能的にはここ1年くらいですっかり見劣りしてしまいました。というよりも、サーバの仮想化エンジンとしての実装は成熟してしまい、純粋な仮想化エンジンとしてはkvm等差別化が難しくなってしまったのに加え、管理機能が充実しているXenServerやVMWareが無償で提供されるようになってしまったため、事実上というよりも実務上存在意義を失ってしまったような状態だと思います。
ソースコードが全て公開されているとかOSS的な側面ではメリットはありますが(Citrix XenServerもCDイメージでソースコードは配布していますが、中身みてないので詳細はわかってないですすみません)、ビルドが面倒、設定が面倒、運用が面倒と非常に手間のかかるプロダクトになってしまいました。大抵の場合、Redhat,CentOS,debian,ubuntuなどにインストールして使うとは思うのですが、自分でビルドするのは大変だと思うので、rpm系であればディストリビューション付属か、http://www.gitco.de/linux/あたりを使用するのがいいと思います。デスクトップやノートPCでお試しするだけなら、Vmware ServerやVirtualboxをお勧めします。

と、ネガティブな話ばかり出してしまいましたが、決して不満なだけではないです。性能面では問題ないですどころか、素晴らしいですの賛辞を贈りたいくらいです。一般に言われる仮想化する事でのオーバーヘッドに関しては完全仮想化するプロダクトに比べオーバーヘッドは少ないですし、dom0で使用されるlinuxとの親和性もありlinuxを扱うのが苦にならない人にとっては扱いやすいプロダクトだと思います。仮想サーバへの移行でよく言われるオーバヘッドについては、ハードウェアの性能の向上スピードが早いようで、あまり気にしなくてもいいんじゃないかと思います(ただしディスクIOを除く)。
1つの仮想サーバの過負荷が他の仮想サーバへ悪影響をもたらすのが心配みたいな、仮想化を導入するにあたって躊躇するシステム担当者がよくする言い訳(あえて言い訳と言います)も問題なくこなしていて、一つの仮想サーバが過負荷で大変な事になっていても、隣のサーバへの影響は排除してくれますし、ハードウェアを抽象化しハードウェアに依存しない実行環境をプロダクションレベルで提供してくれている実績は多いに評価しています。RedhatはKVMで置き換えようと努力はしていますが、安定性に関してはXenに分があるように思えます。

実際、Xenは非常に安定して動作してくれます。Xenのハイパーバイザー自体がトラブルになるような事例には直面した事がなく、トラブルになるとすればXen自体よりも運用におけるオペミスの方が多いのではないかと思います。というか、経験上Xenのトラブルは大半がオペミスです。学術目的で開始したからこそなのかもしれませんが、単体のサーバを仮想化して運用するだけでしたら、Xenは間違いなく良い選択肢だと思います。それが、複数台でストレージを共有してクラウドっぽく運用しようとしたとたん、全てはDIYになってしまうところが学術目的からスタートしたXenならではなのだと
思います。ここがOSSのXenの最大の弱点だと思います。

例として適切かどうかわかりませんが、linuxで既に割り振られているIPを割り振ってインターフェースを起動しようとすると、IPアドレスが重複していてインターフェースが起動できないのがエラーメッセージと共に表示されるのですが、OSSなXenは「それやっちゃうとトラブルを引き起こすかもしれませんのでやめておきます」みたいな未然にトラブルを防ぐ部分に関してはフォロー不足だと思いますし、安心してプロダクション環境に使用できない遠因となっていると思います(それ故XenServerのようなプロダクトが出てくるのだとは思いますが)。

また、仮想化で話題になる「仮想サーバを停止する事なく別の物理サーバへ移せる機能」については、OSSのXenにおいては期待しない方がいいでしょう。忙しいサーバだとマイグレーションが失敗するのは珍しくありません(仕組み上当然ではありますが)。同じ事をやるにしても、この辺りはVmwareが一日の長があるようで、知人に聞いても物理サーバの性能限界近くまで使う仮想サーバだと、ビジネスではVmwareが最終的に選択されるとの事らしいです。機会があればVmwareの製品もいじり倒してみたいです。
Xenのマイグレーションの実装は、メモリイメージの転送を30回行って、30回以内に転送中に更新されたイメージを転送しきれないとマイグレーションが失敗して、マイグレーション先で再起動するような動作だったと思います(3.3あたりでは)。

また、実際に使用するにあたっては単純なネットワーク構成だとトラブルなく導入できるとは思いますがNICのボンディングやタグVLANあたりを使用するようになると、非常に苦労することになると思います。CitrixがよくないのかXenのコミュニティが良くないのかはわかりませんが、NICのボンディング周りはニーズは非常にあるのにXenのソースコードにはバックポートされないんですよね(参考)。XenServerではGUIでポチッとするだけで作業が完了するのに。

その他複数のXenで共有ストレージを使用するとなると、設定は全てlinuxベースの設定が必要となります。普段からlinuxを触っている人はいいかもしれませんが、門外漢の人にはハードルが大会かもしれません。NFSクライアントとか、iscsiイニシエータの設定とか、クラスタLVMの設定とかは慣れていない人にとっては学ぶところからスタートなので、それなりに大変かも知れません。

というわけで、Xenを利用するのであれば、ある程度linuxのセットアップできる管理者がいるのが前提で1台完結型の開発環境として手軽に使用する分にはおすすめだと思います。基本的にはバージョン2.6のlinuxが稼働するx86環境では動くので、Citrix/Vmwareなどベンダーの出している製品に比べればハードウェアの選択肢が多いと思います。とは言え、fedora/Redhat陣営はkvmに舵を切っているので、開発環境だけとして使用するのであれば、kvmの方がいいかもしれません。

予想以上に長くなってしまったので、今回はOSSのXenのみとして、次回は別の仮想化エンジンに触れたいと思います。Xenつながりで、次回はCitrix XenServerをターゲットにします。Vmware Server, OSS kvm、vSphereとかはあまり触ってないので…な部分もありますが。

元々は近所の大きなバイクショップに内装セットを買いに行ったのですが、今まで使っていたJ-FORCE IIが後継のJ-FORCE IIIの発売により販売終了になるような感じで、店内には内装セットの在庫が全くない（というか、J-FORCE II自体も売ってない）状態。
お盆の時期の外出に向けてみんな買って行ったのか分かりませんが、くたびれたヘルメットの内装セットを買っても古いヘルメットを使いつづけることになるので危ないし、いい機会なのでJ-FORCE IIIを購入。セールで\32,000程度でぼちぼちの値段。印象としては、
持ってみると先代よりも明らかに軽い
走っていると増えたアッパーインテークの穴の効果か、先代よりもかなり額あたりが、涼しい
という感じで、定価も数千円上がってますけど納得。
で、喫煙所にいた20代前半と思われる男子数名の会話。
A 「一番色々落とせるソフトってやっぱりwinny?」
B 「音楽ファイルならyoutubeでいいんじゃないの?」
A 「今limewireも使ってるんだけどウイルスとかあるっていうし、俺ウイルスソフト持ってないんだよね」
B 「じゃあ開かなければいいじゃん。開かなければ大丈夫」
びっくりした。ある意味、漢。潔い。個人情報まき散らしても知らんけど。

xenはゲスト起動時に/dev/pts/以下にキャラクタデバイスを作って
xenconsold経由でゲストのコンソールに接続しているようなのですが、
xenconsoldが落ちると/dev/pts以下のキャラクタデバイスがなくなったりします。
このような場合に上記のようなエラーが出ます。
ps a | grep xenconsold
などとしてxenconsoledが立ち上がっていない場合は、
sudo xenconsold
とすれば再度/dev/pts以下にキャラクタデバイスを作ってくれるので、
xm consoleで再度繋げるようになります。