Linus氏曰く「仮想化は悪」 114
ストーリー by hylom
しかし世界はそれに同意せず 部門より
しかし世界はそれに同意せず 部門より
eggy 曰く、
Linus Torvalds氏がLinuxの主要開発者の1人であるGreg Kroah-Hartman氏との対談において、「XenとKVMのどちらが好ましいか」という問いかけに対し「仮想化は悪」と答えたそうだ（本家/.、NETWORK WORLD記事）。
Torvalds氏はかつては最新カーネルへの対応に遅れていたXenに期待しておらずKVM寄りであったとのことだが、「Xenの開発者はフィードバックに耳を傾けるようになっており、今は主流カーネルにも追いついている」とXenを評価した。また「Xenは、KVMとは違った考えを持っており、ハードウェアの制約も違う」、「選択肢を持たせたいから両方ともやっている」とのこと。
しかし、Torvalds氏の個人的な意見としては、どちらも好みではないようだ。実装のハードウェアに直接触れることを好むTorvalds氏は、「俺は仮想化タイプの男じゃないんだ。仮想化は悪だと思ってるよ」と語ったとのこと。
そんな大層な意味はなくて (スコア:5, すばらしい洞察)
「仮想化って邪道だとおもうんだよねー、Linusとしては。
やっぱハードは直接叩かないとねー」
くらいなニュアンスでしょ。
Re:そんな大層な意味はなくて (スコア:2, すばらしい洞察)
好みじゃない、という程度の意思表明だよね。
いつもの怒りと違って、全然暴言が入ってない。
1を聞いて0を知れ!
Re:そんな大層な意味はなくて (スコア:2, おもしろおかしい)
>「やっぱハードは直接叩かないとねー」
という理由で仮想化を叩いていたわけでは無かったのですね？
Re:そんな大層な意味はなくて (スコア:2, 興味深い)
少し深読みすると、LinusがLinuxカーネルを書こうと思った動機は
当時386のプロテクトモードが活用されておらず、16ビットのリアルモードが
全盛だったことに業を煮やしたからというのは有名な話。
当時の状況を少し振り返ると、実際にはプロテクトモードが活用されてなかった
わけじゃなく、386が持っていた仮想86モードを使うemm386や、Windows 3.xの
vmmといった形で利用されていた。つまりユーザーは仮想86モードを使っていた
というか使わされていたというか。
x86ハッカーだったLinusにとって仮想化はいつか見た光景であると同時に
業を煮やしたことそのものかも。その点ではブレがないのかなとかね。
Re:そんな大層な意味はなくて (スコア:1)
見事な要約(と思われる)に感服致しました。
#元記事は読んでません…。
Re:そんな大層な意味はなくて (スコア:1)
CPU屋「もうクロック上げられないどうしよう、そうだコア複数積んじゃえ」
ソフト屋「えー、マルチスレッドとかめんどくさいのに」
ソフト屋「あ、仮想化してCPU1個づつ割り当てればいいじゃん！」
リーナス「美しくないから嫌い」
Re:そんな大層な意味はなくて (スコア:1, おもしろおかしい)
OSそのものの開発やってる人なら、まあそうでしょう。
しかし、最近は仮想マシンの技術が何のためにあるのか知らない奴が多いんだね。
「仮想マシンはパフォーマンス悪くて使えね～」とか、逆に「仮想マシンでどんなOSでも動かせるから最高」とか、わからんことばっか言いたがる。
意味不明なこと言わずに、メインフレーム時代の技術と伝統を受け継いで（？）新OS検証・新OS移行作業・旧OS保守の道具としてVirtulaPCやXPmodeを提供してるMicrosoftは大人の会社ですな。（不思議とこういうところだけはキチンとしている）
まあ、当てにするな (スコア:4, おもしろおかしい)
Re:まあ、当てにするな (スコア:1, おもしろおかしい)
夏休みの生徒へイオン化傾向を思い出させてどうする
Re:まあ、当てにするな (スコア:2, おもしろおかしい)
外から余計なエネルギーを与えられれば、相思相愛のものですら離れていくと言う戒めですよ
# 書いてて意味が解らなかったｗ
好みの問題？ (スコア:3, おもしろおかしい)
好き嫌いを言うだけでこんなに注目されるなんてLinux教の教祖も楽じゃないな。
#高級言語に対して「男ならアセンブラだろ」と言ったようなもんぢゃね？
Re:好みの問題？ (スコア:1, おもしろおかしい)
Re:好みの問題？ (スコア:5, おもしろおかしい)
では、まず仮想ハードウェアを筺体から出してください
Re:好みの問題？ (スコア:1)
Re:好みの問題？ (スコア:2, おもしろおかしい)
穴のあいた紙テープを読み取ってこそ本物のプログラマ（違
画期的な問題解決手法なのか問題の先送りなのか？ (スコア:2)
仮想化で解決できる問題は、仮想化以外の方法で(より少ない資源で)実現できるとか色々言いたいんだろうけど..
運用の自由度の価値を軽視し気味なんじゃないだろうか？
サーバ・クライアント問わず。
Re:画期的な問題解決手法なのか問題の先送りなのか？ (スコア:3, 興味深い)
>運用の自由度の価値を軽視し気味なんじゃないだろうか？
運用の自由度というか、運用側にとって仮想化システムは「ちゃんと
運用考えないで相乗りしているだけなので、以前のサービスレベルは
達成しえない」ということで、運用受け入れしているわけなんですよ。
>サーバ・クライアント問わず。
クライアント側についてはサービスレベルは「それがあるサーバで
落ちたら、別の(クラスタとか)システム上で稼働させたらいいね」で
通るのだけど、サーバ側は、そうもいかない。
サービス監視／バックアップ／ジョブ制御のみっつが大本になる
サーバ運用で、その３つが非仮想化ではある程度のSLAに基づいて
運用されていても、仮想化ではどれかがデグレートしてしまう場合
があって、結構、問題になる。
実際、仮想化して相乗りしました、D2D2TとかD2Dに移行できる？
それって相乗りした全部が一時にやって問題ない？それらが実行中に
フェイルオーバしてもオケ？で回答が出てこないorその場合はCEが
いく,,とかなって、相乗りシステムの多さからCEが対処不能のとか
結構あったんだよね。
運用屋としては、「うん、こういうマシンダウンがあったら手を付け
られないので、保守屋さんがんばってね..」なSLAしか結べないわけな。
個別単体なら同一状況筐体を用意するで「まぁ、SLA的にはオケ」な
わけなんだけどね。
仮想化も使いようかと (スコア:2)
ただ、待機系の予備環境を１台のマシンに仮想マシンとして沢山インストールしておいて、
本番環境に大きな問題が発生したときに、とりあえず切り替えて
やり過ごす様な使い方は、有用だと思います。
VFSは？ (スコア:1, 興味深い)
基本的にOSの進化というのは、ハードウェア資源を仮想化することで取り回しよくしてきたものだと思います。
最終的に、マシン1台まるごと仮想化できるようになっただけで正常進化でしょう。
Re: VFSは？ (スコア:1)
んーにゃ、例えば何をアップデートしても再起動がいらないシステムとか、顧客にサーバをサービスとして貸し出したときに顧客が自分で一通り何でもできると思えるようなシステムとかだ。仮想化それ自体は現存するもののうちではそれに一番近いものを実現できる手段以上のものではない。
気持はわかる。非常に屋上屋くさい。 (スコア:1)
だが、ならばLinuxをそれをしないで済むようなものにしないとな。
みなさんDisられてますね。 (スコア:1)
やっぱきちんと結婚してリアル2.0作ってる人は違うね。
FreeBSD脳 (スコア:1)
仮想化が重いならjail [wikipedia.org]使えばいいじゃない.
# でもFreeBSD jailでCentOSを動かす [mycom.co.jp]という発想は無かった
Re:FreeBSD脳 (スコア:1)
chrootは弱すぎて, 今日では適応可能な状況が限定されすぎます. 例えばプロセスやネットワーク, rootで動かすなら(あるいは権限昇格などのバグがあったら)デバイスやメモリ空間等もアクセスできちゃうので, よっぽど念入りに, 信頼できる機能に絞って設定しないと危険です.
FreeBSD jailは, 一般的なchroot jailのこうした問題点を考慮して実装されているので, かなり安全になっています. ただシステムリソースを使い尽くすタイプのDoS攻撃に対しては開発途上というところみたいですけど.
仮想化はad hocな解決策 (スコア:0)
OS作っている人は、仮想化など不要な作りにしたいでしょう。
Re:仮想化はad hocな解決策 (スコア:2, 参考になる)
>Linus的にはメインフレームも嫌いというか美しくないと思ってるのかな？
というか、メインフレーム的な高可用性のための大量リソース保持を嫌っているのだと思う。
それなりそこそこにシステムの相乗りが出来る状況を作った(つもり)なのに、それが利用されず、
無闇とリソースを喰う仮想化によるシステムの相乗り状況を嫌っているんだと思うな。
人的／CPU的なリソースの集約化はある面よいのだけど、重篤問題発生時にそれが一気に
サービス提供失敗に結果するわけで、それらを含めて考えたら単体Linuxに分離することで
回避できるだろ？なぜそれをしないで「仮想化集約」と言いたいだけのためにリソースを
無駄にするんだ？といったところだと思いますよ。
メインフレームの持っている「他のメインフレームとの動機／システム継続」機能は、
単体のLinux(UNIX)でも維持できるのに、サービス提供側としてのスタンスを忘却した
「闇雲な仮想化／重層化」を毛嫌いしている様に見えますし、それはそれでリーズナブル
な意見だと運用屋としては思います。
Re:仮想化はad hocな解決策 (スコア:1)
Re:仮想化はad hocな解決策 (スコア:1)
>お高いメインフレームならいざ知らず、
いや、メインフレームも結構値下げしてますよ。
>PCなら今や数百ドルでも買えるんだから、もう一台買えって話じゃね？
そのPCに無理矢理詰め込んでどうなの？可用性要求を詰め込むことで
無理矢理高めてどうすんの？＞たかだか数百ドルでも買えるPCに求める？
ということだと思いますよ。
Linusカワイイ (スコア:0)
TO
当然では？ (スコア:0)
せっかくOS作っても、仮想マシンで動かすだけじゃ物足りないですよ。
(デバッグには便利だから利用はするとしても)
Re:当然では？ (スコア:1)
私は逆かなぁ。
もしOS作るならハードに依存する面倒な部分は仮想マシンの抽象化に任せてOSの中核部分だけやりたいな。
Re:当然では？ (スコア:1)
>もしOS作るならハードに依存する面倒な部分は仮想マシンの抽象化に任せてOSの中核部分だけやりたいな。
逆だろ？
OS作るならハード叩き方をエレガントかつ迅速にして、アプリにどれだけ迅速かつ安価にリソースを引き渡せるかが問題になる。
OSの中核でハードから逃げて、何をするのか？と言いたい。
ディスパッチャとかローンチャをOSだと思っていないかい？
Re:当然では？ (スコア:1)
どこが中核かは視点によるんじゃないでしょうか。
私はOSのAPIをデザインし直したいってのがあって、それを実現するのに必要な部分ってかんじかな。
Re:当然では？ (スコア:1)
>私はOSのAPIをデザインし直したいってのがあって、それを実現するのに必要な部分ってかんじかな。
それはOSのAPIデザインの問題であって、OSが本来持つサービス連携や
HW仲介のデザインとは異なる、ある種瑣末な事項ではないのかな？
OSって何？というと、HWやサービスの連携手法によって、サービス
提供可能な環境を提供することであって、デザインのためにあるもの
ではないですよね。デザインは提供することで作られる「結果的なモノ」
であって、それは「どれだけエレガントにやるか？」という問題はある
にしても、OSに求められる本来的なモノではないですよ。
むしろ、OSに求められるのは新しいHWや新しいサービスについて、
旧来と同じデザインのインタフェースで追従できるか？の方が大きな
問題です。それが出来ない時にはじめて連携のための手法をとりいれて
インタフェースのデザインも多少の見直しが必要になるわけです。
逆に、新しいインタフェースに基づく旧来部分もそれに収斂させて、
デザインが一新されちゃって旧来の遺産が動かなくなるってのは、
結構な問題になるんですよ。
Re:当然では？ (スコア:1)
Re:当然では？ (スコア:1)
>そういうのはそれが必要な人がやれば良いです。
うちらとしてはんなもんいらんがな..なわけなんですが、
なぜか入れないとサポートしないとか無理を言うのがいてね。
運用屋さんとしては、「またかよ」なんだけど、あちらとしては
必要なのか、単にやりたいのかわかりません。
Re:当然では？ (スコア:1)
>それWindowsやSolarisだけかと。
>LinuxやOSXだとAPIをばんばん変更して行って、周りがあわててついていくって感じです。
それはあるね。なもんで互換性とか結構シビアな局面になったりするね。
アップグレード前の稼働確認なんか、ベンダーで下手に作り込んでいると
お持ち帰りのケースが結構あって、それでリリースが遅れたり中止になった
りとかの問題もある。Windowsが結構昔は酷かったけど、最近はそれほど
でもないかな？
Re:当然では？ (スコア:1)
>ハードを叩くのはドライバの仕事だね。
CPUというハードを叩く、ってかCPUの命令に即して動くモノで
あれば、ドライバ以外もハードを叩いているよね。インタプリタ
とかだと、話は別だけどね。
>「リソース」と「リソースへの使用権」を混同してはいけないと思う。
うん、混同はまずいよね。
でも、それを混同する発言は見当たらないけどね。
Re:当然では？ (スコア:1)
まぁその通りなんですけれど、昔ブートローダからOSを書こうとして投げ出した身としては
ハイパーバイザ上での準仮想化を前提とした中身空っぽのMock OSなら手が届くんじゃないかと思ってるんですよ。
それはOSじゃないと言われるかもしれないけれど。
性能 (スコア:0)
実機の持ってる性能が仮想化でかなり減らされるんだけど
案件によってはハードウェア分割の方が良さげだったりするな
Re:性能 (スコア:1)
>実機の持ってる性能が仮想化でかなり減らされるんだけど
それあるよね。
某所でのサイジングで、仮想化ソフトウェアが奪うIOパフォーマンスの
換算指標みたいなのがベンダーから出ていて、いくつかの大手ベンダー
のを見たけど、概ね1.5倍から2倍程度のCPU/仮想CPU/coreをアサイン
すべしみたいな感じね。DBMSの大手さんのだと、もっと悲惨だったりする。
でもって、相乗りするサービスの最大CPU使用率／CPUパフォーマンスから、
その最悪値で加算したりするもんだから、旧型CPU(最新の半分以下のもの)が
合計10CPUの仮想化で、最新CPU(core)数で20とか、むちゃくちゃなサイジング
になったりして、「全然HW的に安くないんですけど」になったりね。
>案件によってはハードウェア分割の方が良さげだったりするな
というか、よくできた仮想化集約案件でない限り、HWも安いんだから、
HW分割でやった方がよくね？という試算ができちゃったりする。
運用要件の煩瑣化と運用レベルのデグレートを引き受けるほどにHW
の低廉化は見込めないというのが、今まで数件仮想化案件のサイジング
や方式設計をやってきた上での感想なんだな。
わけがわからないよ (スコア:0)
ストレージの一部をメモリのように扱ったり、連続していないメモリ領域をあたかも連続しているようにプロセスに見せたり、適用範囲の差こそあれ仮想化の概念は古くから使われてるじゃん。
いまさらOSの仮想化のみ取り出して好き嫌いもないもんだ。
Re:わけがわからないよ (スコア:1, すばらしい洞察)
そういうのと、「kernelを二重に走らせる」ってのは全然違う。
無駄でしょ。
Re:相変わらずのキチガイっぷり (スコア:4, おもしろおかしい)
最近のほうがまるくなっていませんか？
体型的にも。
Re:相変わらずのキチガイっぷり (スコア:1, すばらしい洞察)
> 「Xenの開発者はフィードバックに耳を傾けるようになっており、今は主流カーネルにも追いついている」
> 「Xenは、KVMとは違った考えを持っており、ハードウェアの制約も違う」
> 「選択肢を持たせたいから両方ともやっている」
これらの意見のどこが煽りなのか？
インタビュー全体のなかからセンセーショナルな部分だけを抜き出してタイトルにするから、
こうやって踊らされる人が出てくるんでしょうね。
Re: (スコア:0)
意見を求められて意見を言って、どうして「煽り」になるねん。
Re:相変わらずのキチガイっぷり (スコア:3, 参考になる)
まあいるよね、余計な一言言っちゃう人。
Re:相変わらずのキチガイっぷり (スコア:2)
Re:Appleを見習え！ (スコア:1)
Re:久しぶりに思い出した (スコア:1)
OSASKは仮想化と言うよりUserModeLinuxとかcoLinuxとかWINE的なAPIラッパでやろうとしてるんだと思うけど？