UML FAQ

有限会社デジタルインフラ

とくに注記のないばあい、原則として2002/6ぐらいの事情を反映した記載となっています。

UML って、オブジェクト指向のアレと関係あるの？

ずばり、まったくありません！。
オブジェクト指向のほうは、「Unified Modeling Language」であり、こちらは、「User Mode Linux」です。

UML を一言で言い切ると？

「Linuxだけしか動かない代わりに、動作の軽い VMware」です。
すごく無理やりですが・・・。

Jeff Dike 氏って何者？

われわれも、メールでしか連絡を取ったことがないので詳細は不明ですが、いろいろ調べたところ、アメリカのニューハンプシャー州（ニューヨークよりさらにヨーロッパ側にある州。ボストンよりさらに北。日本との時差は１４時間！冬は寒いです。）にすむ男性のようです。 MIT卒業で元DECでUNIX開発グループ所属。現在は、本業としては、 http://www.addtoit.com の CTO を勤めているようです。

いまは、UMLは何に使われてるの？

新システムのテスト用です。
アプリ、ディストリ、rc ファイルなど、いろいろなものにたいするテストに使えますが、とくに、新カーネルのテストには、すでに実績があるようで、 Alan Cox さんなども、関心があるようです。
そのメリットは？と聞かれれば、いまのところは、クラッシュした場合の被害が少ない、 gdb をつかったソースレベルでのカーネルデバッグが簡単、 gprof や gconv もつかえる、とかですが、今後は、たとえシングルCPUのマシン上で実行していても、UMLの中に人工的に任意の数のSMPを作ってしまえるようにする、とか Jeff Dike さんはいっているので、今後大幅に改良されるであろうLinuxのSMPのスピンロック関係の開発なんかにもいいでしょう。なにせ、もってないハード用のカーネルのデバッグができますから。

今後のUMLの使われ方は？

もちろん、それは、ユーザの動向など、さまざまな要因によって変化します。
ただ、Jeff Dike 氏の現在の考えでは、いまのようなテスト用などではなく、むしろ、大規模システムにおける性能向上のための手段として使われることを想定しているように思われます。たとえば、複数のLinux マシンをつないでクラスタシステムを作ったときに、そこにおける処理効率や管理効率の向上のために使う、といった考えがあるように思われます。
弊社の考えとしては、多分、ここ数年としては、jailかな、と思います。ただ、今現在としては、jailにつかうには、 UMLの安定度や完成度の問題があり、まだまだ成熟期間が必要でしょう。といっても、UMLの開発のペースは速いので、半年もすれば実用になってしまうかもしれませんが。あとは、教育用でしょう。internet server や tcp/ipの学習用には、いま（2002/6)のバージョンですら十分使えます。今後の改良も考えれば、今年中にも流行するかもしれません。

同様の趣旨のシステムとしては何がありますか？

いろいろありますが、代表的なものを。
順番は、システム負担が軽いが、機能の制約が多いものから順に。

(2003/7概説追加) まず、個々の製品を解説する前に、ウェブホスティング業の現状を概説しておきます。この手の技術は現在、ウェブホスティング業（www.あなたの社名.comが取れますって業者）での使用がほとんどでしょう。で、この業界ですが、とにかく有象無象（弊社も含め）がゴマンといる業界です。理由なんですが、無料なんとかビジネス！と称するまったくカネの取れないビジネス（それってビジネスじゃないけど）がやたら多いインターネット業で、数少ないカネが取れているビジネスだからでしょう。で、この業界の経営のポイントですが、実際には経営的営業的な面こそが勝負なのですが、技術的な面だけ述べると、動く動かない、といったレベルでは、 CGI以外に関しては、linuxにapache 入れれば完璧に動くうえ、機能的にも問題ないです。よって、なーんだ、無料なソフトを突っ込んどけば完璧かよ。そりゃ美味しいな、というのはまったくの間違いとはいえませんし、それが有象無象をひきつける原因のひとつでもあるでしょう。
問題は、それを動かし続けるためには、オタッキーなLinux技術者の職人芸に頼る必要性があるってこと。まあ、諸経費込み年800万もあれば雇えるんで、すなおに雇う、というのが一番正解な気もしますが、それがいやなら、ウェブミンやコバルトを入れれば、 ある程度は素人さんでも使えるかも。現実はそんなに甘くないような気もしますがね・・・。
もうひとつの問題点はCGI。こちらは、linux+apache では完璧に動くとは言い難い。これは、管理者の職人芸のレベルとは無関係に、もともとの「仕様」。これの解決法は三つ。
１、ユーザ側による独自CGIを禁止する。
２、24/365の有人監視をつけ、ケースバイケースで職人芸で対応する。
３、たとえば Linux Secure Virtual Hosting Extension とか、なんでもいいけどなにか新技術を入れる。
---
もちろん、これ以外に「何が起こっても知らん振り」という必殺技もありますが・・・。
仮想ホスト系 apache の <VirtualHost>と同じ技術。 www.yourcompany.com が取れます、といっている業者が採用している技術はほとんどがこれです。: ・Webmin（フリー）
・ ACE（フリー？）
・Plesk（商用）
jail系: ・FreeVSD（フリー）
・ VServer（フリー）
・ensim（商用）
・sphera（商用）
いまのところ、このジャンルではもっとも有名なのはスフェラ（というかホスティングディレクター）です。日本では三井物産が販売しています。三井物産デジタル、とかではなく三井物産本体です。
製品のほうですが、jailとしての機能は、比較的低機能です。むしろ、webmin や cobalt のようなWeb User Interfaceによる管理機能をメインにそれを大幅に改良した製品、という印象です。 WUIにより、コマンドラインは完璧に追放されていますので、管理業務の人件費負担は軽減されます。ただ、それだけではWebmin とほぼ同じなので、 jail「も」入れた商品だな、というのが個人的感触です。三井物産が地道で泥臭いサポートに情熱を傾けてくれるなら、期待ができる商品になるかもしれません。 jailメインではなく管理機能メインの商品として考えても、管理技術の最後の難関、CGIの管理が jail により効率化できるのはスフェラの大きな利点でしょう。
ただ、それ以前に自分とこのウェブサイトの高速化を考えたほうがよろしいかと。とにかくおせーよ。
最近、L7のファイアウォール（リバースプロキシとかL7のロードバランサーでもほぼ同じ）入れてませんか？回線が遅いというよりも、なんかそのあたりに問題があるような雰囲気が。
2003/10 今見たら、立ち直ってました。
いまは、常識的な速度で表示してます。って、それ当然じゃん！。
あと、いま三井物産のサイトをみたら、スフェラのサポートを関連会社に移管するとか。なんでも本丸でやればいいってもんじゃないので、サポート向上になればいいのですが。

Linux Secure Virtual Hosting Extension 製品ではなく技術ですが、2003/4 追加。
NTTの安田泰勲さんによるjail技術の新星。 NTTといっても、必ずしも業務上のそれで開発したわけじゃないみたいですが、 TCP/IPや/proc の jail化まで考えてます。素晴らしい。 FreeBSD の jail を完全に凌駕するスペックです。さらに、スケジューラに手を加え、悪意のあるユーザが異様な負荷のプロセスを走らせても建前としてはホストマシンがハングしないようになってます。さすがNTTですな。かなり期待ができるかも。

(Apr 2003)
This is a brand-new (and great) jail technology from Yasuda@NTT. (NTT is an equivalence company as ATT in USA and BT in UK. ). It is not a product from his jobs at NTT, just a hack in his private time. Despite that ( or because of it) quality is very good even it is still a first release.
This supports jailing of network(TCP/IP), /proc filesystem. and he also made patches to Linux scheduler and it prevent hanging Linux box up when some nasty user runs a huge process to do a kind of DoS attack. Great work also.
I recommend you to check it out his pages here if you have any interest in jail or virtual hosting. He very kindly made English pages for you.

Sandbox System Call API for Linux
linux 用 jail ・・・っぽい。2003/10 追加。
詳細は見てないので不明。

New! 2003/11
Janus つーのがかのバークレー校からきました。
Janus is a security tool for sandboxing untrusted applications within a restricted execution environment.
・・・・だそうです。
仮想OS系: ・ user mode linux（フリー）
・ IBM Z series（商用）
・ Virtuozzo（商用）
(2003/4追加） 2002夏ぐらいから、Virtuozzo がすさまじい勢いで追い上げています。 UMLやSphera なんかもがんばってはいるのですが、もともとVirtuozzoはかなり筋がいい技術の上、ロシアで作っていて人件費などの関係もあるので、この追い上げに営業、サポート、資金などが適切に連携すればかなり有力な候補になるでしょう。
仮想マシン系（CPU限定）: どちらも、x86でx86を走らすことしかできません。
・VMware（商用）
・Plex86（フリー）
仮想マシン系（CPU非限定）: ・ bochs（フリー）
・ simics（商用)

それぞれの技術の違いは？

.: .
仮想ホスト（バーチャルホスティング）: 仮想ホストは、アプリケーション（サーバソフト、デーモン）が一台のマシンの中に複数のドメインを作ります。
仮想ホストは、単に複数のドメインの単一マシンへの割り当てを可能にするだけであり、複数のコンピュータを作り出すわけではありません。また、複数のドメインが認識できるのは、そのような機能をもったサーバソフトと、それを可能にするネットワークプロトコルの組み合わせの場合に限られます。
ユーザレベルでのソフトのインストールはできません。
動作速度は高速です。セキュリティも、適切に管理すれば問題ありません。できることの制約が非常に多いのが、唯一最大の欠点です。ウェブと電子メールを独自ドメインで行う、というだけのためなら、優れた方法です。あなたの会社名.com が取れます、といっている業者が採用している方法のほぼすべてがこれです。
JAIL: jail （これは、FreeBSDの用語で、 Linux では、chroot だが、jail のほうが高性能）は、ひとつのOSを複数の領域に分割し、それぞれの領域を、あたかもひとつのOS全体のように使うことができます。
ユーザレベルでのソフトのインストールは可能です。
ただ、通常のOSでは、領域の分割が根本段階の設計には入っておらず、あとから無理やり導入しているため、どうしても、セキュリティなどの面で問題があります。
もし、最初からそのような機能を導入すると、セキュリティの問題は解決するかもしれないが、領域分割機能が不要なユーザにとっては、性能低下の要因になる。
最近、この方式を提供する業者が出てきました。
なぜか、この手の業者はJailを使ってることを明示しないのですが、
いままでのホスティングの限界を打ち破る！
ルート権限がついてくる！すべての設定が自在に可能
などといいながら、どこかに「仮想的に」などとこっそり表示してある場合、まず間違いなくこの方式です。

jailって大したことないじゃーん（既存JAILシステムを使ってみた感想）
jailがあれば仮想OSって不要だよね (技術を単なる知識として吸収した感想）
jailに関しては、以上二つの両極端な印象が流布しているようです。これは、技術の実際を理解すれば、それぞれ実像を正しくは反映していない思い込みであることがわかるとおもいます。

最近、サービスとしても、ソフトとしても、いろんな形でJail のシステムが出てますが、これらに多く見られる点として、自由度より管理を優先して作ってあります。たとえば、 jail技術の極限としては www サーバソフトは、どのソフトのどのバージョンでもユーザが自由にインストールできるのですが、それをあえて禁止し、単なる virtual hosting よりは自由度がある、といったレベルにとどめている実装がよく見られます。もっと具体的にいうと、自作CGI可、としても運用を破綻させないための技術としてjailを使っている例が多いです。 (単なるapache の virtual hosting で自作CGIを許可すると、まず間違いなく運用は破綻する)。現在の市場状況を考えると、このような jail の使用法は正しい選択だと思います。ただ、それらを見て、jailって大したことないじゃん、といった印象を持つのは誤りです。
その気になっていろいろな機能を実装していけば、かなり仮想OSに近い自由度を認めつつ、管理を破綻させない運用も可能だと思います。ただし、そこまでするなら、いっそのこと仮想OSにしたほうがいいと思います。このあたりが、既存JAILシステムにおいて自由度が低い理由でしょうし、仮想OS技術が意味を持つ理由です。
仮想OS系: あるOS（ホストOS)の上に、複数のゲストOSを走らせる。
ゲストOSの中においては、ユーザは、ソフトのインストールも含め、すべての機能を使用できる。また、セキュリティ的にもかなり優れている
ゲストOSは、ホストOSのうえで動くように改造された特殊なOSである。速度的には、本質的にはかなり高速。 UMLが、VMwareと変わらないレベルの速度しか出ないのは、完成度とチューニングにだいぶ問題があるから。といっても、2002/10 現在、UMLの開発は急ピッチで進んでおりますので、所詮フリーウェアだなぁ・・・といったレベルを脱却する日はすぐそこです。
仮想マシン系: あるマシンのなかに、仮想的に複数のマシンを作り出す。
仮想マシンの中では、任意のOSのインストールも含め、すべての機能が使用できる。
仮想OSとの違いは、仮想OSは、ホストOSの上で動くように改造された特殊なOSしか動かないが、仮想マシンの場合、仮想マシンの中で使うOSの種類を限定されません。ただし、仮想マシン方式は、本質的には圧倒的に動作が遅いです。 (VMWareが意外と使えるのは、チューニングが非常に優れているから)。

あのぉ、そんな技術的でマニアックなことではなく、 とりあえずききたいのは、 ふつーにウェブやメールをホスティングしてもらうとき、どう違うかってことなんですが。

どこまでの設定項目を業者側が勝手に決定し、なにをユーザ側の自由に任せてるかの違いになります。いまのインターネットのホスティングのほとんどが、 LinuxにApache、、、といったありきたりの構成ですが、このときにまず理解すべきは、それらの設定は以下の三つの部分に分かれることです。なお、ここの用語は正式なものではありません。
・Linuxの設定（以下、Linux設定）
・Apacheの設定で、サーバ全体にわたるもの（以下、全体設定）
・Apacheの設定で、ユーザ個別に設定できるもの（以下、個別設定）
なお、いまのところ、Linuxの設定をユーザ個別に行うのは困難です。

ここにおいて、システム管理者ではなく、ユーザが自由に設定できる部分を方式別に示します。

方式	Linux設定	全体設定	個別設定	備考
仮想ホスト	×	×	○	やれることが限られてるが軽い
JAIL	×	○	○	ウェブとメールだけだがちょっと高度なことを、というなら向いている。
仮想OS	○	○	○	単なるホームページの枠を超えた展開まで可能。そのわりに、マシンへの負荷はJAILとさほどは変わらない。

いままでとまったく違う独自技術による新世代のウェブホスティング！などと称して、実際には単なるJAILのウェブホスティングをやっている業者が現れています。
方式の詳細を隠してのハッタリ（しかもすぐバレる）のかっこ悪さはおいておいても、じゃあ、次世代のウェブホスティングとして、JAILと仮想OSとどっちがいいの、というのは皆さんも興味があるでしょうが、これは、ウェブの今後の使われ方に依存します。 HTMLエディタでコンテンツを作ってアップロードして、.htaccessで設定できるレベルの設定をして、カウンタやゲストブックレベルのCGIを仕掛けて、といったいまよくつかわれている程度がありますが、次世代のWebというものが、それらの次元の延長であって、ただCGIの自由度を向上させたい、より安全な管理がしたい、などの程度の要求であるなら、それはJAILで十分でしょう。逆に、たとえば、MVCモデルに基づき、HTTPの縛りすら抜け、多様な端末、プロトコルに統一されたサービスを提供し、、などという次元が当たり前になるなら、JAILでは無理で、仮想OSのほうがいいでしょう。すくなくとも、このような場合、JAILで行う利点は特段には存在せず、仮想OSを使う利点は開発環境から実行環境への移行が容易であるという一点をもっても利点が存在しているといえます。
仮想マシン方式ですが、仮想マシン方式の最大の売りは OSを選ばないということですが、ウェブのホスティングのような用途ではそれが利点になることは稀有でしょう。ただ、レガシーシステムの集約による運用コストの削減などにおいては仮想マシン方式は優れています。仮想マシン方式の代表的ソフトである VMware は非常によくチューニングされていて本来ならとても遅いはずの仮想マシンをそれなりの速度で動かしてしまうので、それを考えると、VMware/GSX あたりをつかったレガシーシステムの集約は可能性があるでしょう。

New! 2003/7 仮想専用サーバ、リアル専用サーバ

リアル専用サーバなんて用語があるわけではないですが、ようは、GVNや PROXとかがやってる商売です。で、どっちがいいのよ？ってことなんですが、これに関しては、IBMがSystem/370で30年前に立証したように、 技術が成熟すれば仮想専用サーバのほうが優れています。（仮想化技術の源流のほぼすべては、 IBMが1960年代に研究し、1972年に発売したSystem/370のVM技術に元をたどれる）いまのところは、その「技術の成熟」ってのがだいぶアレなので、かならずしも仮想化が意味があるわけじゃないんですが。

仮想化した場合のメリット：
スケーラビリティ。図を見てもらえればわかりますが、需要に応じて能力を柔軟に拡大できるのは最大の利点でしょう。このあたりの、ガートナー社の毎度毎度のハッタリの利いた記事なども参考になるかと。こことこことか。ユーティリティコンピューティング、とかのキーワードで検索してみてもいいでしょう。
また、信頼性もあります。RAIDなどが低コストで可能ですし、プロセスマイグレーションなどと組み合わせれば、 CPUの故障なども対応できます。 UMLでもサスペンド（ハイバネーション）をつかってこれを可能にできる日がそのうち来るのではないでしょうか。

リアルにやる場合のメリット：
ユーザ側ではなく、ホスティング業者側のシステム開発費（設備購入費用ではない）の安さ。単にL3SWと1UのPCの動作検証をするだけでも極論すればOKだから。あとはトラブルの少なさでしょう。普通のPCサーバそのものなので、相性問題などは少ないです。仮想化すると、どうしてもある程度の相性問題は避けられません。

図：仮想化の利点

UML は、どの程度の「重さ」？

なにに使うか、によるところが一番大きいでしょう。たとえば、Webサーバに使うとして、さらに、CGIなどはあまり使わず、静的なコンテンツを apache / bind で送り出すだけなら、２０個ぐらいの仮想マシンを Pentium3 1GHz Mem 1Gbyte のマシンの中に作れるでしょう。もちろん、それなりに実用的な性能で。よって、name based virtual hosting に取って代わる、あたらしいホスティング技術としての可能性もあります。
ポイントは、１、メモリは多めに。ここが一番肝心。CPUやI/Oより、とにかくメモリ。２、ひとつの仮想マシンにひとつのIPアドレスが必要。（リバースプロキシをかければ別ですが）。といったことです。

UMLのチューニングのコツは？(new! 2002/12)

たしかに、UMLの完成度が低いのは事実ですが、それ以前に、正しい使われ方をしていないせいで不当な評価を受けていることもあります。まず、以下の４点を確認してください。

・魔法の呪文、tmpfs を唱えているか。
どこまで効果があるかはケースバイケースなのですが、やって速くなる事はあっても、やって遅くなることは、UMLに限らず、 Linux全般でほとんどないです。ずばりやるべきでしょう。
具体的には、ホストOS側で # /sbin/mount tmpfs /tmp -t tmpfs とします。（ゲストOSでやっても無意味。マイナスはないけど）。 tmpfs ってなんじゃ？というばあいは、とてもよい記事（そして翻訳までよい）がここにあります。
・スワップを指定しているか
指定しなくても動作には問題ないので、指定しない人が多いですが、（弊社が書いた雑誌記事でも、全部指定していません・・・）、これも、指定して速くなる事はあっても、指定して遅くなることはないです。ずばりやるべきでしょう。具体的には、スワップ用のディスクイメージを作って（やり方がわからなければネットから落とす）、コマンドラインに ubd7=swap.image とか加え、ゲストOSのディスクイメージの中の/etc/fstab とかに適切にスワップパーティションの指定を入れます。
・よけいなCRONジョブを削除しているか。
とくに、最悪なのが makewhatis のcron です。ああああぁん？なんだ、HDDが異様にガリガリいってるぞぉ・・。とおもって、ps をとってみたときに（ホスト側からでもゲスト側からでもOK)、 AWKどうこう、、、とかが浮かんでいた場合、まずこれです。 ubdへのアクセスがクソ遅いことも手伝い、とにかくイライラします。正解は、こんなのはどうでもいいのですぱっと削除することです。 man はホストOSかgoogleにお願いするのが正解です。
・メモリはあるか
ホストOS＋ゲストOSだけのメモリは必要です。逆に言えば、同じレベルの内容をインストールした場合は、たとえ仮想マシンを一つしか動かさなくても従来の2倍が必要です。さらに、複数の仮想マシンを動かした場合にいたっては・・・。とにかく、メモリメモリメモリ・・・なのが仮想マシンの世界です。 CPUに関しては、複数の仮想マシンが処理能力全開で突っ走ることはまれなので、何とかなります。
・最後の手段、skasモード
今現在（2003/1）、安定性などに若干問題もありますが、速度が上がるのも事実です。いまテストするなら、 Linux純正カーネルの 2.4.19に host-skas3.patch をいれ、それをホストOSにします。（このとき、設定で /proc/mm を有効にすること）。ゲストOSは、 Linux純正カーネルの 2.4.19に uml-2.4.19-45 を入れればOKです。こちらの設定は、（いまやって見た限りでは）デフォルトでOKでした。ホストOSのほうの実行テストは、/proc/ に mm というわけのわからない項目が出現すればOKです。ゲストOSの設定ですが、特に設定しなくてもホストOSがSKAS対応なら勝手にSKASモードで動きます。（mode=ttで強制的にttモードにもできる）また、バイナリも共通で、SKAS専用バイナリはありません。ゲストOSの実行テストですが、ホスト側からPSして、今までとちょっと違う表示(どう違うかはUMLのバージョンに依存する）が現れればSKASで動いています。なお、いまのバージョンですと、なんと、あのスレッドの大群が消失しています。

UMLが遅いんですけど(new! 2002/12)

UMLには、いまのところ、以下のような問題点があり、下手をするとVMwareより遅いことがあります。原理的には仮想OS＞＞仮想マシンのはずなのですが。

・デバッガ用APIをつかった仮想化手法の限界
これは、こと原理的な次元においては最大の問題点でした。これに関しては、Jeff Dike氏も長年懸念してましたが、ついにskasモードが一応完成しました。この skas モードの登場により、半分ぐらいは解決しました。今後のチューニングや改良にも期待しましょう。
・ブロックデバイスのチューニング。
ubd ですが、すごく遅いです。遅い原因は、差分ファイルシステムにあるのではなく、問題は、UMLのブロックデバイス(というか、ブロックデバイスマネージャ）にあります。まず、Linux（にかぎらず、ほとんどのOSの場合）、ファイルアクセスは、以下のような遷移をします。アプリ→システムコール→OS→ファイルシステムのドライバ→セクタレベルに分解 →セクタアクセスのドライバ→実際のHDD。
で、UMLの場合、セクタアクセスのドライバのレベルでトラップして、そこに差分判定を被せた上でホストOSに突入させています。当然、ホストOSへの突入の際は、通常のLinuxのアプリ→OSのAPIコールと同じオーバーヘッドがあります。さらに、ホストOS上ではubdはやはりひとつの馬鹿でかいファイルなので、前述の動作がまた起こります。これだけでも十分遅いだろうなあ。。という感じなのですが、これがかわいく見えるほどの問題点がUMLにはあります。実は、いまのところ、１セクタごとにそれぞれホストOSへの遷移をやってます。連続する複数セクタへの同時アクセスを考えてないんですね。さらに、「同期」オンリーです。ようは、何らかの事情で HDDが一瞬止まれば、UMLもカーネルコンテキストはとまります。非同期処理はできないので、入出力まちの間に別の処理をすることはできません。うひゃーーー。遅いって感じです。ここに関しては、Jeffも問題点を認識してますし、また、Linux2.5でブロックデバイスに対する複数同時入出力が改良されたこともあり、そのうちなんとかなるんじゃあ、という希望的観測を持ってます。
・メモリ管理の問題点
たとえば、同じセクタに対するキャッシュがホストOSとゲストOSそうほうにあったり、開放してもいいメモリ領域を開放できなかったり、と、それぞれが勝手なメモリ管理方式を（それはそれで、新規のメモリ管理方式の実験が容易だという点ではメリットでもあるのですが）とっていて、さらに、両者の横のつながりがまったくないことにより、不効率を生み出しています。これは、メモリが豊富にあるときは大して問題にはならないのですが、仮想マシンがメモリを大量に使うことからしても、やはり、現実的には大きな問題になります。ここに関しても、Jeff は問題点を認識していますので、希望的観測としてはそのうち何とかなると思います。

UMLのボトルネックについて

仮想化することによるオーバーヘッドですが、たいしたことはないです。ここは、ハードウェアレベルで仮想化をしている bochs や Plex86に対する決定的な利点です。
ただ、仮想マシン内部では、init などのデーモン類が、そっくり動いていますので、その部分に対する「重さ」はあります。余計なデーモンを極力立ち上げないディストリビューションを使ったほうが効率的な活用ができます。それと、UMLはホストOSに手を加えず、さらにルート権限もないのに仮想OSを可能にしているのですが、じつは、現状では、それはデバッガ用のAPIを使うことにより可能にしています、それが問題で、速度のことを考えずに作ったAPIなので、ここが遅いです。
これが総合的な性能をどれだけ落とすかですが、やる内容によりますが、単純なシステムコールをただひたすら繰り返すだけのベンチマークなどは、場合によっては本物のLinuxと一桁二桁違う結果が出るでしょう。もちろん、そんなのは非常に非現実的な状況ですが。
さらに、ここに関しては、作者の Jeff Dike 氏も非常に気にかけていて、 Ottawa Linux Symposiumにて、こんな論文を発表しています。ようは、Linuxカーネル側に仮想OS用の新APIを作ってくれってことです。
それがカーネルに入るかどうかは結局はリーナスさんやアランコックスさんの判断になってしまうのですが、 Jeff Dikeさんの日記 (2002/7/2)では、

it turns out that Linus likes UML. Alan apparently clued him in that people are using UML for real work, and they care about performance.
リーナスさんもどうもUMLが気に入りました。アラン（Alan Cox）さんはリーナスに、UMLはもう実用的な目的にも使われ始めており、やはりパフォーマンス向上が課題だねと伝えました。

こんなことをいっているので、そのうち解決するでしょう。それ以外に、現状では、あたりまえですがUMLのコードにはチューニングにも問題があります。このあたりを追い込めば、やはり速度向上はあります。

UMLの今後の課題は？

(2002/4)
とりあえず動くよ、というレベルはすでに達成しています。よって、まずは完成度の向上でしょう。バグをつぶし、実行速度をチューニングし、相性問題を解消し、ユーティリティやドキュメントを整備し、そして、宣伝啓蒙活動をおこない、、、といった一連のお約束事は必須です。かってな推測ですが、このあたりが一通り済めば version 1.0 でしょう。
その次に課題となってくるのは、いまのデバッガ用APIを使った仮想化手法から、仮想OS専用APIをつかった仮想化手法に移行することです。これは、だいぶ先になると思われていましたが（理由は、VMware/ESX的に特殊なホストOSを使うならともかく、普通にやるには、 Linus でありAlan Cox であり Redhat であり、、といったところが賛同しないとどうしようもないので。）、最近(2002/7)になって情勢が結構変化し、今年中(2002)にも完成するかもしれません。これも勝手な推測ですが、それが終われば version 2.0 ぐらいでしょうか。
2002/12 追記：
　　　　UML自体の完成度の向上より、むしろ、専用APIの開発のほうが先行しています。
以上は、あくまでUMLの内部技術的な視点でしたが、UMLの実用性がぐんぐん向上している昨今、むしろ、どう使うか、という外部的ともいえる視点のほうがより重要かもしれません。そのために必要なことを列挙してみました。

使用目的	課題	弊社の対応
教育	テキストとディスクイメージの作成 UML Win32 の完成	検討中
仮想ホスティング	管理運用手段の整備 UML suspendの完成	開発中
jail	ディスクイメージ、管理運用手段の整備。具体的には UML Builder for Jail と Webmin for UML Jail 的なシステムが必須。	開発予定

ようは、ディスクイメージ（ディストリビューション）と、それ用の管理運用手段（ツール、手順書、要員育成、顧客基盤の確立など）が欠かせないということです。今風に言えば、「そりゅーしょん」ってやつですか？
(2003/1追記：ここを書いたのは主に2002年の春なのですが、あまり進歩していません。弊社にもいろいろ都合があるので・・・。）

VMware との違いは？

目下、UMLの唯一（？）最大のライバル(というのは本当は適切じゃないんですが)はVMware でしょう。それとの違いを端的に示すと、
VMware = 重い（遅い）。しかし、どんなOSでも仮想マシン内で動く。
UML = 軽い。しかし、Linuxしか仮想マシン内では動かない。
という違いになります。（フリーか商用か、というのは除く）。どちらを選択するかは、Linux以外のOSを使用するかどうかで決定すればいいでしょう。
UMLはLinux系の範囲であるかぎりはディストリビューションを選ばないので、 redhat Linux 7.2 の中に、redhat Linux 7.1 の仮想マシンと debian の仮想マシンを浮かべる・・・といったことは可能です。しかし、VMware のように、 Linux マシンのなかに、Windows2000の仮想マシンと FreeBSD の仮想マシンを浮かべる、といったOSの種類を超えた超絶的なことは不可能です。
あと、現時点(2002/6)では、UMLは完成度に問題があるので、いま、即実用で使わなければいけないなら、 VMware のほうがいいでしょう。

UMLの内部構造が謎。とくに、あのスレッドの大群はなに？

UMLは、いまの普通のLinuxに手を加えず、完全にユーザ権限のみで走る単なるアプリケーションとして、仮想OSを実現することをその設計の目標のひとつとしていました。 OSを実現するためには、コンテキストスイッチやMMUなどの、本来はCPU内部の特権モードがないと不可能な機能が必要です。 Linux（と386CPU)に仮想386モードや仮想MMUなどがあればいいのですが、そのようなものはないわけであって、通常は、本物のMMUや本物の割り込みハンドラなどをつかってしまい、そのためにルート特権が必要であったり、OS側に特殊なデバイスドライバや特殊なAPIが必要になりました。しかし、UMLでは、デバッガ用のAPIをつかうことにより、単なるユーザ権限のアプリケーションにすぎないのに、仮想OSを実現しています。ただ、このために、多少トリッキーなつくりになっています。
なお、デバッガ用のAPIを使う現在の構造は性能的な問題があるので、将来的にはLinux側に仮想OSのためのAPIをつくり、それを使うような構造に移行するでしょう。ただ、その場合も、特殊なパッチという形でのAPIというよりは、少なくとも最終目的としては、通常のLinuxカーネルがわにそのAPIを入れてしまうような方向性のほうが好ましいと思います。これを最終的に決めるのはもちろん Jeff ですが。

具体的な構造ですが、詳しい構造はここでは省略しますが、以下に概念図を示します。まずは、システムコールの流れから。UMLのなかのアプリから出したシステムコールがホストOS（本物のLinux）に向かってしまっては大笑いなので、ptrace()をつかってこの流れを無理やり捻じ曲げます。これは ttモード skasモード双方に共通しています。

概念図：

English version here

ここでポイントとなるのは、

・・・このあたりでしょう。

特記：(2002/11)
上のイメージ図からなんとなく想像ができるように、 UMLは、システムコールのたびに４回のコンテキストスイッチをかけており、これが凄く性能上の問題を引き起こしていたのですが、ついに Jeff が立ち上がりました。 skas ( separate kernel address space )というのがそれで、 HostOS側に patchがいるのですが、画期的に速度が上がります。また、ゲストOSのOS空間の保護（jail mode)が完璧になり、さらに性能的なペナルティもなくなります。これが完成すれば、速度的にはVMwareを完璧に凌駕できるはずです。
さらに、UMLが linux 2.6 に入ることが本決まりになった以上、 skas patch も入るでしょう。希望的観測ですが。
さらに、計画段階ですが、kernel mode UMLというのもあります。これは、apache にたいする tux/khttpd のようなもので、 UMLの機能を HostOSの kernel に取り込むものです。これをやれば、さらに速度は向上するはずです。
どこまでがlinux2.6に入るかはわかりませんが、来年(2003)の夏にも登場するこの新カーネルにおいて、本ページで繰り返し説明してきた、「仮想OSと仮想マシンでは速度が根本的に違う」という主張を、事実を以って納得せしめることが可能になると思います。

skas と tt モードってなんだ？(2003/7 New!) what is skas? and tt is what?

これがtt(tracing thread)モード。
This diagram shows how memory is mapped in tt mode.

English version here

このように、mmap() を巧みにつかい、無理やり仮想MMUのようなものを作ってしまっている。なお、ホスト側から $ ps aux をかけたときにスレッドの大群が出現するのは、主に高速化のため。 UML内部のコンテキストスイッチングのたびに mmap() しなおせばあの怪現象は回避できるはず。恐ろしく遅くなるけど。

skas モードはこんなの。
and this is skas mode.

English version here

skas モードでは、ホストOSにパッチを当てて作った専用APIで仮想MMUのTLBの切り替えを非常に高速化（なぜ速いかは、パッチのソースを見てください。動けばいいや、えいや！って香りが濃厚に漂います。）することにより、ttモードの奇妙さがなくなってます。とりあえず、最新のskasパッチを入れたホストOSで最新のUMLを動かしてください。あの変なスレッドはなくなってます。あと、UMLの内部変数がUML上のアプリから覗けてしまう情けない現象も、完璧に阻止されています。この原因は、単にmmap()を掛けまくるオーバーヘッドの問題だったので、やはり勝手APIにより解決できました。
今ですら動作も速くなってますが、今後はもっと高速化するでしょう。うーん。skasモード万歳。唯一の問題点はホスト側に珍妙なパッチを入れなければいけないことです。さてここで考えるのは、じゃあこれが将来のLinuxの公式APIになるのかってことでしょうが、それに関しては、こんな思いつきな機能を入れるわけにはいかない、ってことで、 Jeff Dikeさん（UMLの作者）もLinusさんも、両方とも否定的です。ただし、仮想OS用APIの必要性を否定しているわけではなく、もっとまともなAPIの仕様を策定し、それを将来のLinuxカーネルに正式APIとして入れてくつもりはあるみたいです。

違いを表にまとめればこんな感じかな。

	ttモード	skasモード
利点	ホストOS無改造	動作が速い。メモリ保護が完璧
欠点	動作が遅い。メモリ保護がダメ	ホストOSに要パッチ

skas と tt の読み方：
Jeff Dike さんがなんか言い出せばともかく、現状では正式なものはないんで、適当に発音してください。
弊社内部では、「えすかす」「てぃーてぃー」と言ってますが、これに縛られる必要性はないです。

UMLのネットワークも謎。tuntap って訳わからない。とくに、proxy arp のあたりとか。

これはUMLとは直接は関係ないのですが、ネットでの検索でも、どうやら、tuntap の用途の半分ぐらいはUMLにおける仮想イーサデバイスですし、 Linux kernel の公式ソースツリーに入っているのにもかかわらず、ドキュメントも不足していますので、一通り解説します。
以下の説明は、UMLでの使用法を元にしているので、本来のTUNTAPの使用法とは意図を異にする可能性があります。
概念図：
TUNTAP overview

ようは、IPアドレスでの指定でなにをListenするかを決めて Socket で読む従来の TCP/IP やEtherデバイスの API に代わり、 IPアドレスではなくデバイス名指定でListenして File I/O で読む API です。ただし、どんなデバイスでもListenできるわけではなく、TUNTAPが作った特殊なデバイスだけが読めます。このデバイスは、Linuxの内部にあるだけで、外からは直接は見えません。それが、proxy ARP をかけている理由です。proxy ARP で ETH0 にパケットを吸い寄せ、 ETH0に吸い取られたパケットを # /sbin/route コマンドで設定したpacket forwarding で tap0 に転送します。そして、tap0に転送されたパケットを File I/Oで読み出します。このとき、ioctl で tun モードにしてあると、 IPの raw packet で読め、tap モードにしてあったら ether の生パケットで読めます。 UMLは、ether 生パケットで読み、UML内部の tcp stack により再度ルーティングされます。原理的には、TUNTAPはイーサネットならなんでもOKで、TCP/IP限定ではないと思いますが (まったく未確認です）、パケットを吸い取るときに、少なくともUMLでの使用法を見る限りは、 Linuxの IP ルーティング機構をつかっているので、ではNetWareに応用、、といったところで、多分、IPXルーティングが必要だと思います。

UMLが完璧には動いてない状況で、どうやって設定変更するんだ？

よくあるのが、自分の落としてきたディスクイメージにftpdが入ってなくて、かといって、rpm をダウンロードするにもそもそもftpクライアントからしてどこにあるんだよ！みたいな事態ですね。あとは、/etc/init/rc あたりの設定に一行か二行、致命的な問題があり、それがゆえに立ち上がらない。立ち上げて vi すれば３秒で解決するのに、、、みたいな事態もあります。具体的な状況はケースバイケースだと思うので、ヒントだけ書いておきます。
これを参考に、適当に応用していただければと思います。

トラブルシューティング

そのうち、別ページにまとめます。
なお、謎のトラブルの非常に多くが、UMLが仮想コンソールをデフォルトでXtermにしていることからおきます。もし、telnet でログインしていてトラブルが起きたら、 Xが使えるならX上で使ってみてください。解決策が浮かぶことが多いです。

ブート時に Kernel panic: VFS: Unable to mount root fs on 62:00 とでる

これは、「ディスクイメージが指定されていません」「正しいディスクイメージを指定してください」という意味のエラーです。 UML立ち上げ時のコマンドライン書式をもう一度確認してください。

それ以外で、ブート時(またはシャットダウン時）にハングアップする

ディスクイメージとUMLの相性があります。とくに、H/W関係の設定などでハングすることがあります。ディスクイメージとUMLの組み合わせを変えるか、それとも、不要な設定を削ってください。
ブートしないのにどうやって設定を変えるか、ですが、シングルユーザモードでログインするか、（[dinfra@HostPC] $ linux single ubd0=....）、それとも、ディスクイメージをホストOSからマウントして([dinfra@HostPC] # mount rh72.image /mnt -o loop)、そこで削ってください。

仮想マシン内部からifconfig しようとしたら、 insmod できないといわれた

ホストOS（UML内部ではなく、UMLを実行する本物のLinuxのほう）にTUNTAP デバイスの module があるかどうか確認してください。（/lib/modules/バージョン/kernel/drivers/net/tun.o）。バージョンは uname -r で出てきます。

仮想マシンへのモジュールの組み込みができない

ブート時に、モジュールがない！といわれる

まず、そのモジュールが本当に必要かどうか検討してください。ハードウェア関係のモジュールならほぼ間違いなく不要です。つぎに、 ディスクイメージの中の (ホストOSのファイルシステムにあっても無意味です） /lib/modules/バージョン-リビジョンum/ にそのモジュールがある必要性があります。バージョン、リビジョンは [dinfra@GuestOS] $ uname -r で表示されます。

INIT: Id "2" respawning too fast: disabled for 5 minutes xterm Xt error: Can't open display: と表示される

これは、xterm を立ち上げようとしたがうまくいかない、という意味のエラーです。なぜ xterm が絡むかというと、UMLが仮想コンソールとしてデフォルトで xterm を使っているからです。解決方法は、X window の設定をするか、それとも、con=pty con0=fd:0,fd:1 と指定し、通常のコンソールを指定します。
You don't use X, but you logged in from telnet. right?
This is due to UML's feature that UML use xterm as default console. UML wants to fork Xterm, but there is no X enviroment, then this message comes. To solve this annoying message, one way is set up X :-). other way is put a command line option with "con=pty con=fd:0,fd:1" this option makes your telnet session as default console instead of X.

INIT: no more processes left in this runlevel とか出てログインできない 動いてるっぽいんだが、ログインできない。 デーモンなどは起動してるようだが、ログインできない。 ハングアップっぽいんだが、じつはログインできないだけで動いてるっぽい。 It seems to be running. but you cant logged in. Every daemon seems to be running. but you cant logged in. It seemingly hangs up. but you feel it is no problem. it runs. but just cant logged in.

(2002/年末ごろ？)
これも、基本的には、UMLの仮想コンソールの仕様の問題です。デフォルトでは、仮想マシンのコンソールにホストOSのxtermをマッピングしてくるので、そのあたりに原因があると思います。とりあえず、Xの設定をして、それでうまくxterm が出てきてログインできれば、原因の半分は究明できます。Xなんかつかうのはイヤだ、という場合は、上の項目同様、con=pty con0=fd:0,fd:1 を指定するか（つまり、仮想マシン側のコンソール設定をかえるのではなく、UML側のマッピングをかえる）、それでもうまくいかないのなら、ディスクイメージの中の/etc/inittab をホストOSから直接編集してください（この場合は、UMLのデフォルトのマッピングにあわせて、仮想マシン側の設定を変えている）。
This is also due to console system design of UML and it is feature of UML. Most easiest way is to set up X. if you dont want to do it, cast a magic spell. "con=pty con0=fd:0,fd:1" will help. or change /etc/inittab properly fitting to your console setting of HostOS. remember, /etc/inittab which you have to change is inside of GuestOS. not on HostOS.

(2003/7追加)
最近、UMLのコンソールの仕様が変わって、普通のLinuxとおなじ inittabでOKです。 UMLのバージョンなんとか以降・・・みたいなのはそのうち追加しておきますが、とりあえずご参考まで。

普通の /etc/iniitab。いま(2003)のUMLの inittab でもある。

x:5:respawn:/etc/X11/prefdm -nodaemon
0:2345:respawn:/sbin/mingetty tty0
1:2345:respawn:/sbin/mingetty tty1
2:2345:respawn:/sbin/mingetty tty2
3:2345:respawn:/sbin/mingetty tty3
c:2345:respawn:/sbin/mingetty serial/0

昔(2002)のUMLのinittab。

# Run xdm in runlevel 5
# xdm is now a separate service
x:5:respawn:/etc/X11/prefdm -nodaemon
0:2345:respawn:/sbin/mingetty ttys/0
1:2345:respawn:/sbin/mingetty ttys/1
2:2345:respawn:/sbin/mingetty ttys/2
c:2345:respawn:/sbin/mingetty serial/0

UMLのmake がうまくいかない

UMLは、単独のソースとしてではなく、Linuxカーネルのソースへのパッチとして配布され、 Linuxカーネルソースの make の機構にそっくり依存しています。実際に作り出されるものは、片方はカーネルイメージで片方は単なる ELF フォーマットの実行ファイル（もちろん、その内部にはLinuxカーネルがそっくり入っています）であってまったく違うものなのですが、コンパイル機構を借用している関係で、UMLは、linuxカーネルのアーキテクチャ「um」として定義されています。
make menuconfig / make dep / make linuxの３ステップでコンパイルしていると思いますが、常に、ARCH=um をつけることを忘れないでください。ひとつでも付け忘れると失敗します。
なお、2.5系列の場合、開発途上だけあって、コンパイルに失敗することは結構あります。この場合、不要なコードをコンフィグで外してください。すくなくとも、ハードウェア関係のドライバは一切不要です。UMLでは、ハードウェアはUMLが用意した特殊な仮想的なドライバ経由でしか一切認識されません。よって、いままでのLinuxのハードウェアのドライバは一切不要です。それ以外でも、開発途上のドライバは相性問題などあります。よって、まず、「まじ？こんなに外していいの？」というレベルまで外して、それで動いたらだんだん増やしていく・・・という対応がいいと思います。

jail オプションをつけて起動したら、モジュールと hostfsがあるので、、とか言われた。

エラーメッセージから対策は自明ですが、それは安全性を高めるためのUMLの仕様です。その二つのオプションをオフにしてコンパイルしなおしてください。

ディスクイメージにいろいろインストールしていたら、ディスク不足になった

いまのところ、ubd デバイスはサイズきめうちなので、最初にディスクイメージを作るときのサイズによっては、いろいろインストールしているうちにディスク不足になります。そうした場合は、いちばん簡単な解決法は、「空の」ディスクイメージがありますので、それを適当なマウントポイントにマウントします。linux ubd0=rh72.diff ubd1=empty.image でたちあげ、[dinfra@GuestOS] # mount /dev/ubd/1 /mnt でOKです。もちろん、実際には、/mnt ではなく、目的に合ったディレクトリにマウントしてください。

ネットワークが見えない

まず、UMLとは無関係の、普通のLinuxと同じトラブルシューティングをやって下さい。ping や netstat、ifconfig や route は全部やりましたか。ブート画面（dmesgで参照可能）になにか出ていませんでしたか？/var/log/messages に何か出ていませんでしたか？tcp wrapper (/etc/hosts.allow)やPAMやiptables(ipchains)の設定はどうなっていますか？(iptables -L / ipchains -L で参照可能)。xinetd/inetdの設定はどうなっていますか？/etc/xinetd.d/デーモン名でそのデーモンが disable されてませんか？/sbin/chkconfig --all はどうでしょうか。ps aux をして、デーモンの状態を見てみましょう。各デーモンが吐き出すログもチェックしましたよね。デバッグモードや verbose モードがあるデーモンなら、それで立ち上げたらどうでしょうか。tcpdumpはとりましたか？ホストOS側からでも、ゲストOS側からでも、どちらでもtcpdumpはできます。pingやsynが飛ばないのか。コネクションは確立するのだがそのあと即切断されるのか。データ転送まで行って、認証でハネられるのか。どこで失敗していますか？
・・・が、ここまでいろいろやっているのにもかかわらず、やはりネットワークが見えない場合、それはやはりUMLの問題である可能性があります。その場合は、以下のようなところをチェックしてください。

UMLのリンク集

そのうち、リンク集のページとしてまとめるつもりですが、とりあえず。

UML総本山 http://user-mode-linux.sourceforge.net: 説明は不要かと。
UML CVS src tree http://sourceforge.net/cvs/?group_id=429: CVSクライアントソフトがなくても、ウェブブラウザだけでアクセスできます。ウェブサイトのコンテンツも、XMLでここに入ってます。
UML Win32 http://umlwin32.sourceforge.net: Linux On Windows を可能にする脅威のプロジェクト。完成が待たれます。完成すれば、「ウィンドウズサーバなら一応わかるんだけど・・・」といったレベルの管理者（ITの専門職というよりは、職場のITリーダー的存在に多い）の教育なんかには最適でしょう。
UML suspend http://sourceforge.net/projects/suspend-uml/: ようは、UML用のハイバネーションなんですが、仮想マシンのすべての状態をハイバネのファイルに落として、ほかのマシンのUMLに転送できるので、プロセスマイグレーション的な応用が可能です。具体的にいえば、マシンの更新をノンストップでできます。クラスタリングのフェイルオーバーのように、一度デーモンを落として新マシンで再起動するのではなく、新しいマシンにそっくりプロセスの状態を移行できます。ちょっとこれにはJeffも驚いているようです。実にいろいろな応用法が考えられるでしょう。非常に期待が持てるプロジェクトです。
UML builder http://umlbuilder.sourceforge.net/: UML のディスクイメージを作るツール。つくれるディスクイメージは限定されますが、XのGUIでお手軽です。コマンドライン版もあり。
mkrootfs http://www.stearns.org/mkrootfs/rootfs.html: UMLのディスクイメージを作るツール。だいぶマニアック。そのほか、「空の」ディスクイメージなどもあり。
gbootroot http://sourceforge.net/projects/gbootroot: これまたUMLのディスクイメージを作るツール。

Copyright(c) 2002 Digital Infra, Inc. All rights reserved.
禁無断転載