システム奮闘記：その79
VMware ESXiの運用と仕組みについて
(2009年6月22日に掲載)
はじめに
2009年の正月、VMwareESXiという仮想化ソフトを使って
社内のサーバーの統合を行った。
その時の話は「システム奮闘記:その77」で書きました。
(VMwareESXiのインストールと設定)
あまり項目も触る箇所もないため、ボタン操作で簡単運用と思っていた。
でも、そこに落とし穴があった。
というわけで、VMwareESXiの運用の話と、VMwareESXiの
簡単な仕組みについて触れたいと思います。
VMwareESXiでサーバーの統合化を行った。
そのため以下の構成図になった。
| VMwareESXiで統合化したサーバーの構成図 |
|---|
 |
|
社内向けサーバーを1台に集約した。
|
VMwareESXiでサーバー機能を集約した物を詳しく見ると
以下の図になる。
| VMwareESXiでサーバー機能を集約した様子 |
|---|
 |
XeonのCPUが4個。実メモリ4GBのサーバーに7つの仮想OSの搭載。
1個の仮想OSにつき、1つの機能と決めて、機能の分散を行った上
シンクライアントの実験のためWindowsXPまで搭載してしまった。
|
さて、VMwareESXi上に仮想OSを搭載する際、仮想CPUの数と
仮想メモリ(各仮想OSに割り当てるメモリ量)を選択できる。
| 仮想CPUの数を決める画面 |
|---|
 |
インストールする仮想OSが利用する仮想CPUの数を決める。
仮想OSのインストールの際、全て「1」を選んだ。
|
| 仮想OSが使用するメモリ量を指定 |
|---|
 |
| 拡大図 |
 |
この時は仮想OSが使うメモリ量を512Mバイトに指定した。
今回、購入したサーバーは4G搭載だ。
しかも、4Gを各仮想OSに固定した量を配分する形ではなく
全仮想OSに4Gを割り当てる事ができる。
そして、ある仮想OSがメモリに空きがあれば、必要な所へ融通する形になる。
でも、そんな事を最初は知らなかったため、4Gの配分を考えてしまった。
|
そして以下のように各仮想OSに対して仮想CPUは1個にし
仮想メモリは256MBと512MBと用途によって割り当てた。
| 個々の仮想OSに割り当てた仮想CPUの数とメモリ量 |
|---|
 |
仮想CPUは1個のみにして、仮想メモリ量は感覚的に
十分であろう量を割り振った。
|
この状態で稼働させ、問題なく稼働していた。
ここで「問題なく稼働していた」という過去形に注目された方は
鋭いと思います。
実は、生半可な知識を手に入れたため、ロクでもない事が発生しました。
その話を書きたいと思います。
仮想メモリの融通機能
まずは仮想メモリについて余計な知識を知る事になった。
仮想OSの仮想メモリは、片方が足らなくなったら
余っている方から融通してもらえる機能がある事を知る。
| 物理的なメモリと仮想メモリ |
|---|
 |
仮想OSには、それぞれ仮想メモリが割り当てられている。
だが、それは実メモリとは別物なのだ。
|
だが以下の機能がある事を知った。
| 仮想メモリ同士の融通が可能 |
|---|
 |
仮想OSの仮想メモリ同士の融通が可能だという。
一体、どういう事なのだろうか?
|
もし、仮想OSに割り当てるメモリ量の合計が
実メモリの量を越えてはならない場合、以下のような設定になる。
仮想OSに割り当てるメモリ量の合計が
実メモリの量を越えてはならない場合 |
|---|
 |
実メモリが1GBなので、2つの仮想OSに対して半分づつの
512MBのメモリを割り当てたとする。
|
もし、片方にメモリを非常に消費する処理が行われた場合
以下の事が発生する。
| 片方にメモリを非常に消費する処理が行われた場合 |
|---|
 |
上図の右側の仮想OSに大量にメモリを消費する処理があり
512MBで足らない場合、ハードディスクにスワップする。
でも、左側の仮想OSは、十分にメモリがあり余っている。
片方でメモリが足らないのに、片方では余った状態という
偏った状態があるのは、ハードウェアの資源の有効利用が
できていない状態だ。
|
そのため以下のように仮想OSの割り当てるメモリの合計は
実メモリ量より多く設定可能なのだ。
仮想OSに割り当てるメモリの合計を
実メモリよりも多く割り当てが可能 |
|---|
 |
実メモリは1GBなのだが、2つの仮想OSには
それぞれ仮想メモリの量を1GBつづ割り当てる。
実メモリは1GBなのだが、仮想メモリの合計は2GBになる。
|
この方法を取れば、以下のような利点がある。
| メモリの融通が可能になる |
|---|
 |
もし、片方でメモリの消費が増えた場合でも
もう一方の方がメモリを消費していない場合
もう片方で余っているメモリを融通する事が可能になる。
これによってメモリを無駄のなく最大限に活用する事ができる。
|
これを知った私。
仮想メモリの合計が実メモリの量を越えても良い!
だが、前提として、正しい処方を行わないといけないのだが
そんな事は知る由もなかった。
これが生兵法を引き起こす原因となった話を後述します。
仮想CPUとは
最初、仮想OSに割り当てたCPUは1個だった。
| 仮想CPUの数を決める画面(VMware ESXi) |
|---|
|
VMwareESXiをインストールし、仮想OSを入れ始めた時
CPUの数とは思わなかった。
「Number of virtual processors」の文字を見て
数字はCPUの番号で、どのCPUを割り当てるのかの設定だと
勝手に思い込んでいた。あとから仮想OSに割り当てる
仮想CPUの数だという事を知った。
|
仮想OSのインストールした後、CPUの番号といっても
よくわからなかったので、全て「1」にした。
結果的には、全ての仮想OSに仮想CPUを1個割り当てたのだ。
だが、VMwareESXiでは仮想OSに割り当てられる仮想CPUは
最大4である事を知った。
| VMwareESXiでは最大4つの仮想CPUの割り当てが可能 |
|---|
 |
上図のように、各仮想OSに割り当てる仮想CPUを
1〜4個まで指定できる。
|
以上の事を知った。
仮想CPU、仮想メモリの割り当て変更
「善は急げ」とばかりに仮想OSの仮想CPUの数と
仮想メモリの量の配分を変更する事にした。
| 仮想CPU、仮想メモリの割り当て変更後の様子 |
|---|
 |
負荷がかかりそうな仮想OSに仮想CPUを複数個割り当てた。
そして、メモリをたっぷり割り当てた。
これだと各仮想OSごとに使える資源が増えるので
処理が高速化するかもしれないし、高速化しなくても
急激な負荷がかかっても問題なく処理が行えると思った。
|
だが、この設定を行う上での最大の問題は
正しい知識を身につける事!
なのだ。私の場合、かじった程度の知識だ。
もちろん、生兵法は怪我の元。
VMware ESXiサーバーに異常。仮想OSの処理が重たくなる
さて、仮想OSの仮想CPUの数と仮想メモリの量を変更して
これで、より快適に使えるだろうと思っていた。
だが、社内では次の声が出てきた。
メールの取り込みができへん
| メールの取り込みができない様子 |
|---|
 |
これが出るようになった。
何人かの利用者から「取り込めない」という苦情が来た。
|
メールサーバーの反応が悪い。
そして、別の苦情が来た。
Webの閲覧が遅くなった
日本エフセキュアー社のLinuxウイルスフィルターを使って
プロキシーを行っている。プロキシーはメールサーバーに入れている。
詳しくは「システム奮闘記:その43」をご覧ください。
(エフセキュアー社のLinux版ウイルスゲートウェイの設定)
苦情が出てくる。しかし原因がわからないので
なんでやねん・・・
と思った。
思い当たる事は、仮想OSに割り当てた仮想CPUの数と
仮想メモリの部分だ。
ネットを調べてみると日経ITproに以下のサイトがあったので
読む事にした。
独自の仕組みでx86アーキテクチャ上に仮想化を実現(4)
サーバーに複数個のCPUがある時、どのようにして
処理が行われるのかの話の部分だった。
サーバーに複数個のCPUを搭載している場合、
どのように仮想OSの処理に割り当てているかの概略だ。
図にすると以下の通りになる。
| 仮想OSへのCPUの割り当て方法 |
|---|
 |
|
仮想OSが列を作って順番づつ処理する形をとっている。
有償のVMwareESXでは、一回の処理に20ミリ秒の時間を
与えているようだ。
無償のVMwareESXiも基本的には同じ仕組みなので
おそらく20ミリ秒だと思う。
|
そして複数のCPUを搭載しているサーバーは
同時に複数の仮想OSの処理をしている。
| 同時並行で複数の仮想OSが処理される |
|---|
 |
4つ搭載しているため、同時に、いくつかの仮想OSが処理できる。
上図の場合、仮想CPUを2個割り当てられた仮想OSが
2つやってきたが、仮想CPUは2個づつで、合計4個のため
同時に処理ができる。
|
だが、不用意に仮想OSに複数の仮想CPUを割り当てると
以下の問題点が発生する。
| 不用意に仮想CPUを複数個割り当てると発生する問題点 |
|---|
 |
現在処理中の仮想OSに割り当てられている仮想CPUが1個でも
すぐ後ろで待っている仮想OSの仮想CPUが4個の場合
同時に処理するためには、実CPUが5個必要になるが
この場合、4個しか実CPUがないため同時処理ができない。
この間、3個のCPUが暇を弄んでいる状態になっている。
ここで無駄が発生しているのだ。
|
これがわかった時、まさに不用意に仮想OSに
複数の仮想CPUを割り当てているやん・・・
という事で、全ての仮想OSの仮想CPUを1個に割り当て直した。
| 仮想CPUの数を1個にした |
|---|
 |
仮想OSに割り当てる仮想CPUは1個にした。
でも、仮想メモリの割り当て量は、たっぷり割り当てたままだった。
|
これで解決かと思ったのだが、相変わらず・・・
メールの取り込みができへん
| メールの取り込みができない様子 |
|---|
|
だった。どうもメールサーバーの反応が悪い。
どうしてメモリをたっぷり割り当てているのに・・・。
そこで仮想メモリの割り当て量を元に戻す事にした。
| 仮想メモリの量も元に戻した |
|---|
 |
仮想OSに割り当てる仮想CPUの数と仮想メモリの量を
全て最初に割り当てた状態に戻した。
|
すると・・・
問題解決したのだ!!
これで一安心だ。
堕落したIT担当者から脱却を目指す
VMwareESXiの場合、ちょっとした仮想化サーバーとしての運用だと
システムの概略を知らなくても、マウス操作だけで事足りると思っていた。
まぁ、勉強するのも大変なので、後回しにしていた。
だが、今回の事件を重くみた私は
これではアカンやろ
と思った。
原因を追求する必要があると思ったと同時に
ある程度は、VMwareESXiの仕組みを知らなければ
円滑なシステム運用ができないと考えた。
そこでマウス操作で簡単運用の域を超えるため
以下の本を購入した。
VMware徹底入門(翔泳社:著・ヴイエムウェア株式会社)
そう、堕落したIT担当者からの脱却を目指す事にした。
VMwareESXiのメモリ消費について
仮想OSに仮想メモリを割り当てるのだが
もしかして、以下の法則があるのではないかと思った。
快適に仮想OSが稼働するための
仮想メモリと実メモリとの関係 |
|---|
 |
ところで、仮想OSを使っている場合、仮想OSの物理メモリは
全て実メモリのアドレスに変換される。
この変換はバカにできない事を知った。
メモリのアドレス変換。
よくある話としては、個々のプロレスが認識する
論理メモリのアドレスと、実際のマシンのメモリ
即ち、物理メモリのアドレスとの間の変換だ。
| 論理アドレスと物理アドレスについて |
|---|
 |
論理アドレスとはプロセス側から見えるメモリのアドレスだ。
物理メモリとは、実際のメモリのアドレスになる。
以下の図のように、OSには論理メモリと物理メモリの間には
アドレス変換表があり、プロセスが指定のアドレスを指すと
それを物理アドレスへ変換してくれる仕組みになっている。
|
 |
なぜ、こんな仕掛けを行っているのか。
以下の理由があるからだ。
| なぜアドレス変換する仕組みがあるのか |
|---|
 |
論理メモリとは、あくまでもプロセスから見たメモリのアドレスだ。
論理メモリのアドレスの事を、プロセスの仮想アドレスとも呼ぶ。
ところで、LinuxやWindowsといったマルチタスクOSの場合
複数のプロセスが稼働しているため、プロセスから見たアドレスを
そのまま、実メモリのアドレスに使ってしまうと
2つ以上のプロセスが同時に同じアドレスを取得しようとすると
衝突が発生する。
その上、プログラム開発上、複数のプロセスがお互いを意識させながら
物理アドレスを使い分けるのも困難な状態だ。
そのため、上図のように、個々のプロセスには見せかけのアドレスとして
仮想アドレス(論理メモリ)を用いて、メモリ管理を行いやすくし
プロセスが見たアドレスと、実メモリのアドレス(物理アドレス)を
変換させる仕掛けがあるのだ。
|
さて、このアドレス変換なのだが、ひとつ問題を抱えている。
それは、変換表をメモリ上に置いているのだが、
意外と変換表がメモリを食うのだ。
| メモリ変換表はメモリを食う |
|---|
 |
アドレス変換のために変換表のために
メモリを食うのは、いささか変な話のような気がするが
結構、食うようだ。
|
簡単に、論理アドレスから物理アドレスへの変換の話を
書いてみました。
復習を兼ねて、詳しく書いても良いかと思ったのですが
そこまで書く元気がないのらー!!
なので、簡単なままで終えました (^^;;
| メモリ変換について詳しく知りたい方へ |
|---|
「はじめて読む486」(アスキー出版局:蒲地輝尚)がお薦めです。
MMUとかページング機構について、詳しく書かれています。
私が読んだのは、この原稿を書く4年前の話で
それ以来、ほとんどメモリに関しては勉強や復習をしていないため
すっかり忘れていますし、読み返すだけの元気がないため
簡単な説明にとどめました。手抜きではありません (^^;;
|
さてさて、論理メモリと物理メモリの変換の話を踏まえた上で
仮想OSと実メモリとの話に進めていきます。
| 仮想OSの仮想メモリと実メモリについて |
|---|
 |
仮想OS内でも、論理メモリと物理メモリがある。
だが、その物理メモリは、あくまでも仮想OSに割り当てられた
仮想メモリであって、本当の実メモリではない。
|
仮想OSは、複数あるため、仮想OSに割り当てられた
仮想メモリのアドレスと、実メモリのアドレスとは一致しない。
先ほどの論理メモリと物理メモリのアドレス変換と同様に
仮想メモリと実メモリとの間にもアドレス変換が行われている。
| 仮想メモリと実メモリとの間にもアドレス変換が行われている |
|---|
 |
仮想OSに割り当てられた仮想メモリのアドレスから
実メモリのアドレスへの変換のための変換表がある。
|
ところで、このアドレス変換表はメモリ上に存在する。
このアドレス変換表には、論理アドレスと物理アドレスの変換表と同様
メモリを食うという問題がある。
| アドレス変換表はメモリを食う |
|---|
 |
一体、どれくらいメモリを消費するのか、数値で見る事ができる。
| 仮想OSの仮想メモリ量とアドレス変換のためのメモリ量 |
|---|
 |
| 桃色で囲んだ部分を拡大 |
 |
桃色で囲んだ部分が仮想メモリの量と、仮想OSの維持に必要な
その他のメモリ量(Memory Overhead)の量になる。
仮想メモリ1GBに対して、100MB近いメモリが必要なのだ。
|
なんと100MB余分に必要なのら-!!
1GBの仮想メモリに対して、余分に100MBのメモリが必要なのだ。
とんでもなくメモリを消費するのだ。
もちろん、100MBがアドレス変換に全て使われているかどうかは
わからないが、それにしてもメモリの消費量の多さには驚く。
そこで仮想メモリ量と、余分に必要なメモリ量の相関関係の表を
載せてみる事にした。
仮想メモリ量と、余分に必要なメモリ量の表
(32ビットCPUが1個の場合) |
|---|
| 仮想メモリ量(MB) | 余分に必要なメモリ量(MB) |
| 256 | 87.56 |
| 512 | 90.82 |
| 1024 | 97.35 |
| 2048 | 110.40 |
| 4096 | 136.50 |
| 8192 | 188.69 |
| 16384 | 293.07 |
| 32768 | 501.84 |
| 65536 | 919.37 |
日本ヴイエムウェア社が配布している資料から引用しました。
仮想メモリの量を増やすと、余分に必要なメモリ量は増えるのだが
増加の度合は大きくない事がわかる。
むしろ、仮想メモリを256MBしか設定していないのに
余分に消費するメモリ量が88MBあるので
エグいほどメモリを食うのらー!!
もちろん、この表は、仮想CPUを32ビットで1個にした場合で
仮想CPUの数や、64ビット用にした場合では、仮想メモリ量と
余分に必要なメモリ量との相関関係は変わってくる。
|
仮想メモリが256MBの場合、約88MBの余分なメモリの消費は恐ろしい。
実際に、仮想メモリを256MBに割り当てた仮想OSがあったので
この目で確かめる事にした。
| 仮想メモリ256MBの時の余分に必要なメモリ量 |
|---|
 |
|
余分に取得しているメモリが83.28MBと表示されている。
|
やはり自分の目で確かめると、実感として・・・
エグいほどメモリを食ってるやん!!
仮想OSに仮想メモリを割り当てた際、余分に必要なメモリ量を
考慮しておかないと、メモリ不足に陥る危険がある事がわかった。
仮想メモリ機能(オーバーコミット)について
VMwareESXiにはメモリ融通機能がついている事は前述しました。
実メモリよりも多くの仮想メモリを確保するための技術を
メモリのオーバーコミット
と言われる。
だが、最初、この文字を見た時・・・
日本男児はカタカナはわからんのだ!
何でもカタカナで書かれると理解の妨げになる。
そこで、コミット(commit)を英和辞典で見ると以下の意味だった。
| 「commit」の意味 |
|---|
動詞で「〜に送る」や「〜に委託する」などがある。
名詞の「commitment」には「義務」や「責任」、「委託」がある。
接頭語に「over」がやってくる。
「overCommit」は「無理な約束」がある。
つまり限度を越えたメモリの提供の意味合いではないかと思ったりする。
仮想メモリの合計量が、実メモリ以上の値が割り当て可能にするため
なんとかしてメモリを確保する技術である事から
「無理な約束」の語彙のオーバーコミット(overcommit)が
当てられていると思われる。
|
要するに、実メモリ以上のメモリ量を仮想メモリに割り当てが
可能にするための技術なのだ。
VMwareESX(esxi)では、以下の4つの方法で
オーバーコミットを実現しているのだ。
| オーバーコミットを実現する4つの方法 |
|---|
| (1) |
アイドル仮想マシンへのメモリ税 |
| (2) |
バルーンドライバ |
| (3) |
スワッピング |
| (4) |
メモリのページシェア |
4種類ある事がわかるのだが・・・
カタカナばかりで、わからへん (TT)
なのだ。
システムばかり触っているのだが、年々、カタカナ用語に対して
拒否反応が出てくる。これからは「システム」と書かずに
「系統」と書いたりして (^^)
まぁ、中国では翻訳されているため「システム」は「系統」だし、
パソコンは「電脳」で、サーバーは「服務機」なので、わかりやすい。
ソフトの「軟件」は、直訳でわかりづらいのだが・・・。
アイドル仮想マシンのメモリ税
アイドル仮想マシン。
思わず・・・
小野真弓の写真入りのパソコン
を連想してしまった (^^;;
カタカナにするから混乱するのであって、英語のままなら
混乱する事はない。
小野真弓の「アイドル」は「idol」(偶像、崇拝される人)だ。
アイドル仮想マシンの「アイドル」は「idle」(怠ける)だ。
単語の綴りは違うが、発音記号を見ると同じなので、綴りがわからないと
「アイドル」だけでは混乱しそうなのだ。
閑話休題。
アイドル仮想マシン。要するに「怠けた仮想マシン」の事だ。
メモリ税の税率の初期値は75%
なんだか江戸時代の悪代官が農民に重税を課して
年貢を絞り取るような感じで、VMwareESXiが仮想OSから
仮想メモリを搾取しているように思えたりする。
だが、搾取するという意味合いとは違うみたいだ。
メモリ税については、以下のURLに説明があった。
アイ・アイ・エムの「メモリ税」の説明
実際に使っているメモリのページを1にして
使っていないメモリのページを「4」にしている。
メモリに重りをつける感じだ。
でも、言葉だけでの説明ではわかりずらい。
そこで図で表しながら説明する事にします。
| メモリ領域 |
|---|
 |
仮想OSには、仮想メモリの領域がある。
仮想といっても、考え方は普通のメモリと同じだ。
|
メモリの量を表す単位はバイトだ。
ところでメモリ管理機構の1つにページング機構がある。
メモリを管理する上での最小単位の塊を「ページ」と呼ぶのだ。
x86CPUの場合、最小単位が4KBになっている。
本来なら、ページング機構の話を書かねばならないのだが
すっかり記憶の彼方なのらー!!
というわけで、ページング機構の話は割愛します (^^;;
| ページという塊に分割できる |
|---|
 |
厳密には、こんな綺麗な形で並んでいないのだが
ページという塊が集まっている様子は想像できると思います。
|
メモリを使っているという事は、使用中のページがあるし
空き領域がある事は、未使用のページがある。
| 未使用のページと使用中のページ |
|---|
 |
メモリの空き領域は未使用のページの集まりだ。
使用中のメモリ領域は、使用中のページの集まりになる。
|
x86CPUの場合、ページは4KBになる。
なので、以下の図の場合、メモリの量を見てみる。
| 1ページ辺り4KBなので |
|---|
 |
未使用ページは4個あるので、未使用領域は16KB。
使用ページは5個あるので、使用領域は20KBになる。
|
ここまでは普通の話だ。
アイドル仮想メモリ税は、未使用ページに「4」という
加重をするというのだ。
つまり以下のような事なのだ。
| 未使用ページに「4」を加重するとは |
|---|
 |
未使用ページに加重「4」をするというのは
あたかも未使用のページを1ページ辺り16KBの領域と
みなす事だ。そのため未使用ページは通常の4倍の領域として
扱われるのだ。
|
そのため以下のような図式になる。
| 未使用ページに加重を行った場合 |
|---|
 |
未使用のページは加重「4」があるため1ページ辺り16KBと計算される。
そして使用中のページは通常通り、1ページ4KBとして計算される。
|
未使用のページに加重を行う事が一体、どんな利点があるのか。
以下の利点があるのだ。
| 未使用ページに加重を行う利点 |
|---|
 |
未使用ページに加重を行っているため、仮想メモリの量が
実際に確保したメモリ量よりも多くなっている。
そのため取得する実メモリの量が少なくて済むため
空きのメモリを多く抱える問題が解消される。
|
空きメモリを多く抱えなくする!
これが利点なのだ!
これにより他の仮想OSが使えるメモリを確保できる仕組みなのだ。
未使用ページへの加重の度合は変更可能なようだが
あまり触る必要がないので、割愛します。
バルーンドライバ
バルーンは風船だ。それにドライバが付くので・・・
風船おじさんが風船を操縦するのだ！
と座蒲団3枚取り上げのギャグを書いてしまいそうだ (^^;;
メモリバルーンはメモリ領域を風船に例えている言葉で
風船のように、メモリ量を膨らませたり、萎ませたりして
仮想メモリのメモリ量を大きさを伸縮させているという。
| 風船の如く仮想メモリの領域の伸縮が行える |
|---|
 |
仮想OSが持っている仮想メモリなのだが、伸縮が可能なのだ。
そのため未使用なメモリ量が多いと、メモリ領域を萎ませたり
必要になれば、限度量(設定しているメモリ量)まで
膨らませる事ができる。
|
この伸縮を行う際に必要な道具として「バルーンドライバ」がある。
VMwareToolsをインストールする際に、一緒にインストールされる
ドライバの事なのだ。
これを導入する利点は、前述している仮想OSのメモリ融通が
行える事なのだ。
| 仮想OS同士でのメモリの融通 |
|---|
|
もし、片方でメモリの消費が増えた場合でも
もう一方の方がメモリを消費していない場合
もう片方で余っているメモリを融通する事が可能になる。
これによってメモリを無駄のなく最大限に活用する事ができる。
|
さて、図で説明しても、論より証拠が必要。
なので、VI Clientの仮想OSの監視画面を見てみる事にする。
| VI Clientから見た仮想OSのメモリ量の推移 |
|---|
 |
| メモリ量の推移部分の拡大図 |
 |
赤っぽい線が「Memory Granted」となっている。
確保が認められたメモリ量だ。変動しているのがわかる。
例え、仮想OSの設定時にメモリ量を512MBに設定しても
不要な分は、仮想化ソフト(VMwareESXi)に取り上げられるため
実質、所有が認められる量が変わってくる。
|
そしてメモリ量が伸縮されている様子、即ち、メモリバルーンは
以下の図になっている。
| メモリバルーンの様子 |
|---|
 |
この仮想OSで、確保したメモリ量のうち、不要だと思われる物は
仮想化ソフトのVMwareESXiによって、取り上げられる。
上図は取り上げられたメモリ量を時間経過の推移のグラフで表した物だ。
この期間の間に、最大で約229MBのメモリを取り上げられている。
|
というわけで、2つの線を、わかりやすい形で
眺めてみる事にする。
| 2つの線を比較してみる |
|---|
 |
時間経過とメモリ量の推移のグラフを見てみると、ある事に気づく。
| 2つの線は上下で対象になっているのでは |
|---|
 |
所有が認められたメモリ量のグラフと
取り上げられたメモリ量のグラフを見てみると
黒い線を境目に、上下対象になっている事がわかる。
もし、上下対象なら、所有が認められたメモリ量の変動幅と
取り上げらたメモリ量の変動幅が同じ事を意味する。
|
そこで2つの線を重ね合わせる事にした。
| 上下対象かどうかを見るため重ね合わせてみる |
|---|
 |
見事の一致する事がわかる。
やはり「百聞は一見」にしかずなのだ。
|
必要なメモリ量を、適切に割り当てる機能があるので
メモリの融通が行われ、円滑に複数の仮想OSを稼働させるのだ。
これを行うには、仮想OSにVmwareToolsのインストールが必要です。
VMwareToolsのインストール方法は後述しています。
スワップ機能
OSにあるメモリ関連の機能でスワップ機能がある。
実メモリが不足した場合、実メモリ内のデータで
あまり使われていない分を、ハードディスクに退避させて
メモリの空き容量を確保する機能だ。
Linuxならインストールの際、スワップ領域の指定を行い
メモリ内のデータを退避させる。
ハードディスク領域を、あたかもメモリ領域に見せかけ
使用可能なメモリ量を増やしている仕掛けなのだ。
| スワップ領域といえば |
|---|
 |
LinuxでもWindowsでもハードディスクにスワップ領域が設けられる。
スワップ領域を、メモリ空間の一部として扱い
メモリの量を増やしているように見せている。
スワップ領域はハードディスク上にあるため
メモリ装置と違ってデータの入出力に時間がかかる。
だが、スワップ機能がある事で、プログラム実行時に
実メモリを越えてデータを処理する場合、
あまり使われていない実メモリ上のデータを、
スワップ領域に移動させて、実メモリに空きを作る事で
コンピューターの速度を低下させない役目がある。
そしてメモリ不足によるシステムの停止を防止できる。
ただし、あまりにもメモリ不足の場合、必要なデータまで
スワップするため、プログラムの実行が、メチャクチャ遅くなる。
プログラムを実行中に、ハードディスクのランプの点灯が
激しい場合なのだ。
|
それと同様に、仮想化ソフト(VMwareESXi)が
実メモリだけでなく、ハードディスクの一部を使って
あたかもメモリ領域に見せる
| VMwareESXiもスワップ領域がある |
|---|
 |
VMwareESXiも、LinuxやWindowsと同様に、スワップ領域を設けている。
これによって、あまり使われていないメモリ上のデータを
スワップ領域へ逃したり、大量にメモリが消費する場合でも
不足分をスワップ領域に割り当てる事で、メモリ不足に陥らなくて済む。
VMwareESXiの場合、Windowsと同様、初期設定の際に
特にスワップ領域の大きさを指定する必要がない。
|
スワップ領域がどれくらい使われているのか。
VI Clinetにあるメモリ監視画面を見てみる。
| メモリ監視画面 |
|---|
 |
スワップ領域の時間経過の推移を見てみる。
| スワップ領域の量と時間経過での推移 |
|---|
 |
スワップ領域を表した線は紫色だ。
この期間のグラフを見ると最大値が約254MBになっている。
あまり使われていないメモリ上のデータが結構多いように思える。
だが、これを行う事で、高速の出し入れが必要なデータを
多く実メモリ上に常駐させる事ができる。
それにスワップ領域のお陰で実メモリが足らなくなっても
スワップ領域の利用が可能になり、メモリ不足による
システムの停止を防止できる。
|
ハードディスクの領域をメモリと見なすスワップ。
VMwareESXiでも使われている事がわかったのだ。
メモリのページシェアー
「シェアー」という言葉。最近、よく聞く。
マンションの一室を共同で借りる事を「シェアーする」と言うし
飛行機の共同運航便の事を「コードシェアー」という。
英語の「share」(共有)から由来するカタカナ用語なのだが
どうして日本は・・・
カタカナを使いたがるねん！！
全く、カタカナにすると、意味がわからんようになる。
その上、カタカナを知っているのが格好良いとか知的だと
思っている人が多い。そんな誤った認識では困る。
ちなみにメモリを日本語にすると「主記憶装置」になる。
メモリのページシェアーというのは、要するに
「主記憶装置におけるページという単位の塊を共有する」手法の事だ。
さて、仮想OS上には仮想メモリがある。
そしてメモリ管理を行う上での最小単位はページになる。
仮想メモリのページは、仮想化ソフトが管理しているメモリ空間の
ページと1対1で対応した関係にある
仮想OS上の仮想メモリのページと
VmwareESXiが管理するメモリ空間のページの対応関係 |
|---|
 |
ここまでなら何とも思わない。
ところで仮想OSは複数稼働しているのが普通だ。
すると以下の問題が出てくる。
| 仮想化OSは複数稼働している |
|---|
 |
仮想化OSは複数稼働している。
もし、上図のように仮想OS上の仮想メモリで、
同じ内容のページを持っている場合が考えられる。
|
もし、何も細工しなければ、以下の無駄が発生する。
| 同じ内容のメモリページが、別個の領域で消費される |
|---|
 |
もし、複数の仮想OS上の仮想メモリで、同じ内容のページがあった場合
何も細工をしなければ、VMwareESXiが管理するメモリ空間上で
別個に消費される。
そのため無駄な部分が発生するのだ。
|
そこでVMwareESXiでは、以下の仕掛けが実装されている。
| ページ共有の仕組み |
|---|
 |
仮想OS上の仮想メモリのページで、お互い内容が共通したページがある場合
VMwareESXiが管理するメモリ空間では、ページ共有が行われる。
そのため同じ内容のページを複数持つ必要がなくなり
その分、メモリの節約になる。
|
実際に、ページ共有されているメモリ量を見るために
VI Clientの管理画面を見てみる事にした。
| メモリ状態の時間推移の画面 |
|---|
 |
| メモリの推移部分を拡大 |
 |
|
いくつもの項目がある。
|
その中で、メモリ共有の部分を見てみる事にした。
| メモリ共有の部分を注視してみる |
|---|
 |
メモリ共有が行われている量と時間推移のグラフだ。
メモリ共有の量を表す線が緑なので見づらいですが・・・。
グラフに表示している時間内での最大共有メモリ量は約144MBだ。
これにより少なくとも144MB分の重複をなくし、メモリの節約している。
ここでの共有メモリ量が、仮想OSが5個あるうちの、2個でも
ページ共有があれば、共有メモリ量に数えられるのか
それとも全ての仮想OSで共有しているページを数えるのかは
わからない。でも、4つの仮想OSで共有しているページが
40MBあっただけでも、40×3=120MBの節約になるため
結構、効果があるように思える。
|
ページ共有の仕掛けを働かせた場合、そのためだけに
CPUやメモリの消費も増える事が考えられる。
それでもページ共有の仕掛けを動かすという事は
あまりCPUを消費しない上、ページ共有のために消費する
メモリ量も多くないのではないかと思ったりする。
あくまでも推測の域を越えないのだが (^^;;
これでメモリのオーバーコミットの4つの手法を全て書きました。
仮想化技術で、サーバーの限られたメモリを上手に活用し
仮想OSをいかに効率的に動かすかの技術を垣間見た感じだ。
CPUの仮想化支援機能とVMwareESXiについて
最近のCPUには仮想化支援の機能がついている。
インテルなら、Intel-VTだし、AMDならAMD-Vといった物だ。
さて、今まではCPUの仮想化支援という言葉を聞いても
おいらにゃ、関係ねぇ！
だった。
だが、メーリングリストで以下の指摘があった。
仮想化支援(VT)対応のCPUが必須なのでは?
この内容を見た瞬間・・・
キチンと調べた事がなかった (--;;
そこでVMwareESXiをインストールする場合、
CPUは仮想化支援機能が必要なのかどうかをネットで調べてみる事にした。
x86仮想化(ウィキペディア)
VMwareESXの場合、64ビットのOSを仮想OSとして使う時に、
仮想化支援機能を使っているという。
ESXとESXiでは基本的には同じなので、64ビットOSの時に
仮想化支援機能が必要となる。
だが、VMwareESXiをインストールする際に
仮想化支援機能が付いたCPUが必須かどうかが書かれていない。
ふと思った。
そもそも今、稼働しているサーバーのCPUが・・・
仮想化支援かどうか、わからへん (^^;;
デルからサーバーを購入したのだが、全てデルに任せていたので
自分で確かめたわけではない。
サーバーのCPUが仮想化支援かどうかを見て、仮想化支援でなければ
VMwareESXやESXiがCPUの仮想化支援機能に依存しない事が証明できる。
使っているのは、インテル社のXeon E5205なのだ。
そこでインテルに問い合わせをした。すると・・・
仮想化支援機能付のもあります
だった。
言い方が曖昧だったので、確証を得た気がしなかった。
そんな中、ふと思い出した。
仮想化OSとして、64ビット用のCentOSをインストールしても
インストールできへん・・・
なのだ。
CPUの仮想化支援のうんぬんを考える前に、64ビットCentOSが
インストールできないかと考え、仮想OSとしてインストールしたのだが
途中で失敗したのだ。
| 64ビット用のCentOSのインストールが失敗する様子 |
|---|
| インストール開始の様子 |
 |
| エラーが出た様子 |
 |
| エラー内容の拡大 |
Your CPU does not support long mode. Use a 32bit distribution.
|
CPUはXeonのE5205なので、64ビット対応になっている。
実際に、サーバー上にCentOS5.1の64ビット用をインストールしたら
問題なくインストールができる。
なので、VMwareESXi上に仮想OSとして64ビット用のCentOSを
インストールして、CPUが対応していないというエラーが出ると
このサーバーのCPUが本当に仮想化支援に対応しているのかどうかが
不安になってくる。
|
もしかして
CPUが仮想化支援に対応していないのでは・・・
インテルからの回答が、曖昧な言い方だっただけに
そんな不安が過った。
そこでサーバーの購入先のデルに問い合わせてみた。
すると・・・
初期状態では仮想化支援機能は無効になっています
有効にするにはBIOS画面で設定してください
だった。
BIOSの画面で仮想化支援を有効にする必要がある。
仮想化支援を有効にして、64ビットCentOSが
仮想OSとして、インストールできれば全て納得できる。
だが、サーバーを止めるわけにいかない。
という事で、状況証拠を集める必要があった。
しかし、その後、色々、ネットで調べたが決定的な記述がない上、
日本ヴイエムウェア社のサイトを見ても・・・
明確な記述が見つからへん (TT)
という事で、直接、日本ヴイエムウェア社に質問する事にした。
すると、以下の回答をいただいた。
| 日本ヴイエムウェア社からの回答 |
|---|
*******株式会社
菅様
いつもお世話になっております。ヴイエムウェアXXXと申します。
この度は弊社製品につきましてお問い合わせ頂き有難うございました。
お問い合わせの件につきまして下記の通りご回答させていただきます。
仮想化支援対応のCPU(Intel-VTかAMD-V)に対応したCPUが必須ではございませんが
ESX Serverは対応可能なホストマシン、デバイスのベンダーに制限がございます。
下記URLにVMware社にて検証がとれているHCL（サポートリスト）を公開しておりますので、ご確
認下さい。
○v3.5用
http://www.vmware.com/files/jp/pdf/vi_systems_guide_ja.pdf
ESXiをご利用の場合は上記リストにサポートされているリリースに、
「ESXi 3.5 Installable」と記載のあるものに限られます。
また合わせて、ESX Serverの最低動作要件も満たす必要がございます。
【ESX Server最低動作要件】
○v3.5用
CPU：Intel Xeon 1500Mhz相当の物×2個（コアではなくソケットとして2個必須）
*一部、インテルQuadCoreのみシングルソケットが認められておりますが、
対象機種については上記リンク先の互換性リストに従います。
メモリ：1GB以上
HDD：内蔵SCSI（SAS）もしくはFibre等の外部ストレージ
*SATAディスクについては一部制限がございます。
詳細は下記 v3.5用クイックスタートガイド P.33をご参照ください。
以上、何卒よろしくお願い申し上げます。
|
VMwareESXiは仮想化支援対応CPUは必須ではない
64ビットCPU用のOSを仮想OSに使う場合は、CPUの仮想化支援機能を使うが
そうでない場合は、CPUの仮想化支援は使わない。
回り道をしながらも、なんとか納得ができる物が得られた。
だが・・・
論より証拠が見たいのだ!
後日、サーバーを止める機会があった。
BIOS画面にしてCPUの仮想化支援の設定を見てみると
初期状態では仮想化支援が無効になっていた!!
ヴイエムウェア社の見解では、仮想化支援を有効にすれば
64ビットOSの仮想OSを動かす事ができるという、
そこで仮想化支援を有効にしてみた。
| BIOS画面で仮想化支援を有効にした |
|---|
 |
そして仮想OSとして、64ビット用のCentOS5.3を
インストールしてみた。
すると・・・
見事にインストールできた (^^)V
これで確信が持てた。
やはり論より証拠なのだ (^^)
CPUの動作レベルと仮想化の仕組み
ところで、CPUの仮想化支援とは、どういう仕組みなのか。
日経ITProのサイトを見る事にした。
1985年以来のアーキテクチャを革新する新技術
この記事を読むと、CPUの仮想化支援機能以前の仮想化の仕組みと
仮想化支援機能を利用した仮想化の仕組みが書かれている。
まずは、CPUの仮想化支援が付属する前の仮想化の手法を
見てみる事にした。
インテルのx86CPUの場合、動作レベルには4段階ある。
| CPUの特権レベル |
|---|
 |
インテルの486以降のx86系のCPUには、4段階の特権レベルがある。
特権レベルの数が小さくなれば、強い権限になるという。
権限とは何かですが、それは、すぐ後に説明します。
|
4段階の特権レベルを用意しているのだが、実際に、WindowsやLinuxで使う
レベルは「0」と「3」の2つだという。
| WindowsやLinuxで使うCPUの特権レベル |
|---|
 |
カーネルプログラムは特権レベルが「0」です。
アプリケーションプログラムは「3」です。
カーネルプログラムは権限が強いという意味です。
通常、特権レベル「0」の状態で動いている事を「カーネルモード」と呼び、
特権レベル「3」の状態で動いている事を「ユーザーモード」と呼ぶ
|
x86CPUでは4段階の動作レベルを用意しているのだが
実際には特権レベル「0」と「3」の2つしか使われていない。
特権レベルに関して詳しい事は「システム奮闘記:その46」
(CPUの特権モード。OSが固まる原因)をご覧ください。
ハイパーバイザー型の仮想化ソフトは、x86CPUで
使われていない特権レベルを利用して、仮想化を実現している。
| 仮想OSのカーネルはレベル1を使っている |
|---|
 |
|
仮想化ソフトをレベル0にして、仮想OSをレベル1にしている。
|
仮想OSをレベル1にしている事で、以下の事が可能になる。
| 仮想化ソフトが仮想OSの制御が可能 |
|---|
 |
仮想OSを、仮想化ソフトよりも1つ下のレベルに置く事で
仮想OSの制御が可能になるし、仮りに仮想OSが暴走しても
歯止めを効かす事ができる。
仮想OSが暴走し、歯止めがかからないと、OSが固まったり
下手をしたらハードウェアの故障の原因になったりする。
|
さてさて、通常、OSはハードウェアの制御を行ったりしている。
そのため、OSはレベル0で稼働しているのだ。
| OSはレベル0で稼働している |
|---|
 |
ハードウェアの制御などは、レベル0のプログラムでないと
稼働しない。そのためOSやドライバはレベル0になっている。
|
仮想化の場合、仮想OSはレベル1という一段階下になっている。
| 仮想OSの場合、レベル1なので通常の場合だと |
|---|
 |
レベル1であっても、レベル0のプログラムが発行する特権命令を
発行する事はできる。
しかし、レベル0のプログラム(OS)が、レベル1のソフトが発行した
特権命令を見て、例外処理を発生させ、エラーを出す仕組みになっている。
|
だが、例外処理を発生させる部分に工夫を行えば
以下の事が可能になる。
仮想化ソフトが例外処理発生を監視し
それを拾い上げるようにする |
|---|
 |
レベル1の仮想OSは特権命令を発行してもレベル0の段階で
例外処理が発生する。
仮想化ソフトは、例外処理が発生するのを監視して
例外処理が発生した時に、仮想OSが発行した特権命令を拾い上げ
それの処理を行う事で、仮想OSの命令を実行させている。
|
利用されていない動作レベルを活用して、仮想化を実現させている。
巧みな技(?)だと思ったりする。
CPUの仮想化支援の仕組み
先ほど、CPUのレベルの違いを活用した仮想化の
仕組みを簡単に説明しました。
だが、レベル0の仮想化ソフトが、レベル1の仮想OSが
特権命令を発行し例外処理が発生するのを監視し
仮想OSが発行した特権命令の処理を行っていたのでは
余分に負荷がかかる。
そこで、仮想化の処理をCPUに委ね、ソフト的な処理の負担を
軽減したのが、CPUの仮想化支援なのだ。
簡単に、仮想化支援のCPUの仕組みを説明します。
| 仮想化支援のCPUの仕組み |
|---|
 |
4段階の動作レベルに加えて、「VMX non-root」と
「VMX root」という2種類の動作状態が加えられた。
VMXとは「Virtual Machine eXtensions」
(仮想マシンの拡張)の略語だ。
|
2つの動作状態は以下のように使われる。
| 2つの動作状態の使われ方 |
|---|
 |
仮想OSは、レベル0の状態で稼働させ、
仮想化ソフトをVMXrootの状態で稼働させる。
そして実際の特権命令をVMXrootの状態に移して
実行させるという仕組みだ。
|
CPUに仕掛けを作る事で、ソフトウェアでの仮想化の動作制御を
肩代りさせる事で、最適な仮想化環境を目指しているというのだ。
ところで、VMwareESXやESXiでは、64ビットOSを
仮想OSにしない限りは、CPUの選択で仮想化支援の有無は関係ない。
ヴイエムウェア社の見解では、CPUに仮想化支援が
搭載されるまでの間に得られた技術などが確立している上
仮想化支援を活用しても、あまり利点がないため
CPUの仮想化支援を活用していないというのだ。
CPU以外にも、I/O(入出力)関連でも仮想化支援の動きがある。
VT-dと呼ばれる物なのだが、ここでは割愛します。
だって、難しいもーん (^^)
CPUの仮想化支援の話だってロクに説明できないのだから
VT-dを調べても、たぶん、討ち死にすると思うのだ。
VMware Toolsのインストール
VMwareESXi上だけでなく、VMWareServer上で仮想OSを動かす際
仮想OSにVMwareToolsというソフトをインストールする。
これの利点は
画面解像度を良くする事なのだ (^^)
実際は、他にもあるが、まずは解像度を良くする話だけにとどめます。
さて、仮想OSがLinuxの場合、どうやってVMwareToolsを
インストールするのかを説明していきます。
| VI Clientの画面 |
|---|
 |
上図を拡大してみる。
| VI Clientの画面を拡大 |
|---|
 |
「Install/Upgrade VMware Tools」を選択すれば良い。
インストール、もしくは新規バージョンへの更新ができる。
|
これ以外にも、仮想OSを呼び出している画面からでも
インストールや新規バージョン更新も可能だ。
|
|---|
 |
| 拡大画面 |
 |
「Install/Upgrade VMware Tools」を選択すれば良い。
インストール、もしくは新規バージョンへの更新ができる。
|
「Install/Upgrade VMware Tools」を選択すると
以下の画面が出てくる。
| インストール開始の有無の選択画面 |
|---|
 |
|
ここは「OK」を押して前に進める。
|
すると以下の画面が出てくる。
| VMware Toolsの選択(VI Client画面) |
|---|
 |
上図だと見にくいので、仮想OSを呼び出した画面で見てみる
| VMware Toolsの選択(VI Clientで仮想OSを呼び出した画面) |
|---|
 |
| 拡大画面 |
 |
RPM形式とtar.gz形式の2種類用意されている。
どちらかを選んでインストールする。
仮想OSがCentOS5系なので、RPM形式を選択する私。
|
RPM形式のファイルを自分のディレクトリーに複製する。
そしてコマンドでインストール作業を行っていく。
| VMware Toolsのインストール |
|---|
[root@server]# rpm -ihv VMwareTools-3.5.0-123629.i386.rpm
準備中... ########################################### [100%]
1:VMwareTools ########################################### [100%]
[root@server]#
|
これだけで終わりではない。
次に設定を行う必要がある。
RPMでインストールした際に、vmware-config-tools.plが
設定用のスクリプトとして用意されるため、それを実行させるだけだ。
| VMware Toolsの設定 |
|---|
[root@server]# vmware-config-tools.pl
Stopping VMware Tools services in the virtual machine:
Guest operating system daemon: [ OK ]
Trying to find a suitable vmmemctl module for your running kernel.
The module bld-2.6.18-8.el5-i686smp-RHEL5 loads perfectly in the running kernel.
Trying to find a suitable vmhgfs module for your running kernel.
The module bld-2.6.18-8.el5-i686smp-RHEL5 loads perfectly in the running kernel.
pcnet32 35141 0
Unloading pcnet32 module
Trying to find a suitable vmxnet module for your running kernel.
The module bld-2.6.18-8.el5-i686smp-RHEL5 loads perfectly in the running kernel.
Trying to find a suitable vmblock module for your running kernel.
The module bld-2.6.18-8.el5-i686smp-RHEL5 loads perfectly in the running kernel.
Detected X.org version
X Window System Version 7.1.1
Release Date: 12 May 2006
? 7.1 : '0.0.0'.1
Build Operating System: Linux 2.6.18-53.1.14.el5PAE i686 Red Hat, Inc.
Current Operating System: Linux XXXX.YYYY.co.jp 2.6.18-92.el5 #1 SMP
Tue Jun 10 18:49:47 EDT 2008 i686
Build Date: 24 May 2008
Build ID: xorg-x11-server 1.1.1-48.41.el5
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Module Loader present
.
Please choose one of the following display sizes that X will start with (1 - 15):
[1] "640x480"
[2] "800x600"
[3] "1024x768"
[4] "1152x864"
[5] "1280x800"
[6] "1152x900"
[7] "1280x1024"
[8] "1376x1032"
[9] "1400x900"
[10] "1400x1050"
[11] "1440x900"
[12] "1680x1050"
[13] "1600x1200"
[14] "1920x1200"
[15] "2364x1773"
Please enter a number between 1 and 15:
[3]
|
自動的に処理が進んでいくが、画面解像度の設定部分で
選択のための待ち受け画面になる。
初期値は[3](1024x768)になる。
|
初期値通り[3](1024x768)を選択した私。
すると処理が自動的に進んでいく。
| VMware Toolsの設定処理の様子 |
|---|
[3] 3
Starting VMware Tools services in the virtual machine:
Switching to guest configuration: [ OK ]
Guest memory manager: [ OK ]
Guest vmxnet fast network device: [ OK ]
DMA setup: [ OK ]
Guest operating system daemon: [ OK ]
The configuration of VMware Tools 3.5.0 build-123629 for Linux for this running
kernel completed successfully.
You must restart your X session before any mouse or graphics changes take
effect.
You can now run VMware Tools by invoking the following command:
"/usr/bin/vmware-toolbox" during an X server session.
To use the vmxnet driver, restart networking using the following commands:
/etc/init.d/network stop
rmmod pcnet32
rmmod vmxnet
depmod -a
modprobe vmxnet
/etc/init.d/network start
If you wish to configure any experimental features, please run the following
command: "vmware-config-tools.pl --experimental".
Enjoy,
--the VMware team
[root@server]#
|
これでVMware Toolsの設定が終わった。
でも、このままでは具合が悪い。
青い部分に示しているように、ネットワークを停止させているのだ。
そのため、このままでは通信ができない状態なのだ。
そこでネットワークを起動させる必要がある。
|
ところでVMwareToolsをインストールした時
仮想OSの設定で何らかの変化があるのだろうか。
Linuxのドライバは、モジュールになっている場合が多い。
詳しくは「システム奮闘記:その72」をご覧ください。
(initrdファイルって何?)
モジュールを取り込む際の設定ファイルで、CentOSの場合
/etc/modprobe.confがある。
VMware Toolsのインストール前と後を比較してみる事にした。
| /etc/modprobe.confの中身 |
|---|
| VMware Toolsインストール前 |
alias scsi_hostadapter mptbase
alias scsi_hostadapter1 mptspi
alias scsi_hostadapter2 ata_piix
alias eth0 pcnet32
|
| VMware Toolsインストール後 |
alias eth0 vmnics
alias scsi_hostadapter mptbase
alias scsi_hostadapter1 mptspi
alias scsi_hostadapter2 ata_piix
# Added by VMware Tools
install pcnet32 /sbin/modprobe -q --ignore-install vmxnet;/sbin/modprobe -q --ignore-install pcnet32 $CMDLINE_OPTS;/bin/true
alias char-major-14 sb
options sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330
|
色がついた箇所が追加された記述部分だ。
イーサネットのモジュールが変更されているため
VMwareToolsのインストール作業中に、ネットワーク機能を停止させ
インストール終了後に、ネットワーク機能を新しい状態で
起動させる必要がある事がわかる。
|
私が調べた範囲では、/etc/modprobe.confファイルの記述が
変更されるぐらいだが、もしかすると、他にも変更されるファイルが
あると思う。
仮想OSを再起動させた。
すると画面解像度の選択が自由に出来るようになった。
VMwareToolsのインストール前後の比較をしてみる。
| VMware Toolsのインストール前 |
|---|
 |
| 拡大画面 |
 |
「640x400」と「800x600」の2種類しか選択できなかった。
これでは見にくい画面のままになってしまう。
|
そしてVMwareToolsのインストール後は以下のようになる。
| VMware Toolsのインストール後 |
|---|
 |
画面解像度の選択肢が増えた。
これによって好みの解像度が選ぶ事ができる。
|
VMwareToolsのインストールの目的や利点なのだが
ここまでは画面解像度の話ばかり書いていた。
しかし、他にも利点がある。
時間同期が挙げられる。
仮想OSの時間は狂いやすい。
そのためVMwareESXiの時刻と仮想OSの時刻を同期させる事で
仮想OSの時刻がズレていくのを防ぐ事ができる。
vmware-toolboxというコマンドを使えば
GUIでVMwareToolsの設定画面を呼び出す事ができる。
| VMware Toolsの設定画面 |
|---|
 |
|
桃色の部分に印を入れれば、時間同期が可能になる。
|
お次の利点。
VMwareESXiの場合、メモリ管理の話でも触れましたが
バルーンドライバ(仮想OS同士のメモリの融通)の機能があるが
この機能は、VMware Toolsを入れて、初めて機能するのだ。
| 仮想OS同士でのメモリの融通 |
|---|
|
もし、片方でメモリの消費が増えた場合でも
もう一方の方がメモリを消費していない場合
もう片方で余っているメモリを融通する事が可能になる。
これによってメモリを無駄のなく最大限に活用する事ができる。
これを実現させるには、各仮想OSにVMwareToolsのインストールが必要だ。
|
VMwareToolsをインストールすれば、VI CLientの画面で
仮想OSの情報が取得できる。
| VMwareToolsインストール前の仮想OSの情報 |
|---|
 |
| 拡大画面 |
 |
桃色で囲んだ部分だが「not install」と表示されている。
その下のネットワークに関する部分は空白になっている。
|
同じ部分を、VMware Toolsのインストール後で見てみると
以下のようになる。
| VMwareToolsインストール後の仮想OSの情報 |
|---|
 |
桃色で囲んでいる部分で、ネットワークに関する情報が
表示されている。都合により公開できませんが (^^;;
|
仮想OSにVMware Toolsをインストールする事によって
仮想OSとVMwareESXiの連携がより深くなる事が言える。
VMware Toolsをインストール後は再起動をお薦め
VMwareToolsのインストールの後は、再起動をお薦めします。
LinuxにVMwareToolsをインストールした後、ネットワークの機能が
停止するため、ネットワーク機能を開始させる必要がある事に触れました。
でも、それだけではありません。
そこで私が遭遇した障害(?)を紹介します。
仮想OSにLinux(CentOS5.3)を使っている私。
そこでVMwareToolsをインストールした。すると・・・
急に重たくなったのらー!! (--;;
| 仮想OSの監視画面(CPUの時間推移) |
|---|
 |
| 桃色で囲んだ部分を拡大 |
 |
CPUの負荷が急激に上がっているのが一目瞭然だ。
このままでは他の仮想OSにまで影響が出てしまう。
|
topコマンドを使って、何がCPUを消費しているのかを
見てみる事にした。
| topコマンドを使ってみた結果 |
|---|
[root@server]# top
top - 17:25:37 up 8:27, 3 users, load average: 2.38, 1.58, 1.10
Tasks: 173 total, 2 running, 171 sleeping, 0 stopped, 0 zombie
Cpu(s): 40.0%us, 60.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 1035292k total, 1021592k used, 13700k free, 24864k buffers
Swap: 530136k total, 60k used, 530076k free, 610680k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10174 root 25 0 8816 2512 2072 R 94.4 0.2 18:53.14 vmware-user
12026 root 18 0 138m 130m 1172 S 1.3 12.9 0:00.11 fsavd
3995 root 15 0 1720 572 476 S 0.3 0.1 0:03.04 syslogd
4908 postfix 15 0 3200 1160 880 S 0.3 0.1 0:00.79 qmgr
12263 root 15 0 2188 1048 796 R 0.3 0.1 0:00.03 top
12267 postfix 16 0 3140 1376 1176 S 0.3 0.1 0:00.01 local
1 root 15 0 2060 620 532 S 0.0 0.1 0:00.40 init
2 root RT -5 0 0 0 S 0.0 0.0 0:00.00 migration/0
3 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
4 root RT -5 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
5 root 10 -5 0 0 0 S 0.0 0.0 0:00.14 events/0
6 root 10 -5 0 0 0 S 0.0 0.0 0:00.00 khelper
7 root 11 -5 0 0 0 S 0.0 0.0 0:00.00 kthread
10 root 10 -5 0 0 0 S 0.0 0.0 0:00.39 kblockd/0
11 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 kacpid
67 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 cqueue/0
70 root 20 -5 0 0 0 S 0.0 0.0 0:00.00 khubd
[root@server]#
|
|
vmware-userというデーモンが仮想CPUを94.4%占有しているのがわかる。
|
何が原因で、こんなにCPUを消費しているのか
全く見当がつかない。
でも、仮想OSの再起動を行ってみる事にした。
すると・・・
CPUの高負荷が消えてしまった!!
ウソみたいにCPUの負荷がなくなり、軽くなった。
なぜ負荷が急激に増えたのかは、未だに原因は不明だ。
しかし、VMware Toolsをインストールした後は、再起動をお薦めします。
パッチを当てる作業
VMwareESXiだが、セキュリティーパッチが不定期的に出ている。
セキュリティー対策のため、パッチ(修正プログラム)を当てる必要が
あるのだが・・・
サーバーを止めるわけにはいかないのらー！！
その前に・・・
どないしてパッチを当てるねん！！
だった。
調べてみると、なんだか有償のオプションが必要な感じがしてきた。
でも、具体的に、何を使えば良いのか、わからない。
そこでヴイエムウェア社に質問のメールを送ったら
以下の回答がやってきた。
| ヴイエムウェア社からの回答 |
|---|
XXX株式会社
菅様
お世話になります。ヴイエムウェアYYと申します。
この度は弊社製品につきましてお問い合わせ頂き有難うございます。
下記の通り回答させていただきます。
******ご質問*******
現在、御社のVMwareESXi UPDATE3を使っていますが、UPDATE4にアップグレードを
行いたいと考えています。
しかし、サーバーは１台しかないため、他のサーバーへ仮想OSを移動させて、
UPDATE4を新たにインストールする方法がとれません。
もし、御社のソフト（無償・有償関係なく）で、仮想OSの移動をせずに、
VMwareESXiをUPDATE3からUPDATE4にするための物が、ございましたら、
教えていただけませんでしょうか。もし、有償でしたら、
価格の方も教えていただけませんでしょうか。
何卒、よろしくお願い致します。
********************
バージョンアップのアップグレードとUpdateの適用とは方法が違います。
Updateの場合は特に仮想マシンをどこかに移動させる必要はございません。
詳しくは下記マニュアルのP119をご参照ください。
<http://www.vmware.com/files/jp/pdf/vi3_35_25_u2_3i_i_setup_ja.pdf>
またESXiの技術的なご質問につきましては無償製品のためマニュアル、
ナレッジベースをご利用いただきセルフサポートとなるか、
オプションでサポートをご購入いただく必要がございます。
オプションでご購入の際には弊社パートナー様からのご提供となりますので
パートナー様へ価格等につきましてはお問い合わせください。
以上、何卒よろしくお願い申し上げます。
|
早速、紹介してもらった手引書を読んだのだが・・・
わからへん (TT)
うーん、困った。思わず・・・
もう、まいっちんぐ!
私が小学生時代に流行したエッチな学園アニメの
「まいっちんぐマチコ先生」の名台詞(迷台詞?)だ。
ついに頭がイカれたかもしれない私 (^^;;
しかし、あきらめずに粘り強くネットで調べてみる事にしたら、
わかりやすく書いているサイトがあった。
夜更かし日記
非常に簡潔で、わかりやすい。これを見た瞬間・・・
付属ソフトなんて要らへんのか！
と思った。
どうやらヴイエムウェア社には、とんちんかんな質問をしてしまった (^^;;
サーバーを止めずに、パッチは当てる事はできる。
しかし、再起動させないと、当てたパッチが反映されない。
普段なら「どうやってパッチを当てよう」と悩んでしまうが
幸いゴールデンウィークが間近だった。
ゴールデンウィークは地元にいる私なので
丁度、ええ時期に連休やん！
5月3日に休日出勤をして、パッチを当てる事にした。
まずはパッチを当てる前のバージョンを見てみる。
| パッチを当てる前のバージョン情報 |
|---|
 |
「VMware ESX Server 3i, 3.5.0 , 153875」がバージョン情報だ。
パッチを当てると、赤い部分の数値が上がっていく。
|
まずはヴイエムウェア社からパッチをダウンロードする。
ヴイエムウェア社のパッチ、アップデートのダウンロード
Windows上にパッチをダウンロードをする。
| ダウンロードしたパッチ |
|---|
 |
|
データの大きさは225MBある。デカいパッチなのだ。
|
パッチはZIP形式で圧縮がかけているので、LHAなどで解凍を行う。
| LHAでパッチを解凍する |
|---|
 |
解凍した結果、フォルダーが出来た。
できたフォルダーの中に、パッチが入っている。
|
早速、フォルダーの中に入ってみると
また、圧縮ファイルがあるやん！
だった。
| 圧縮ファイルが3つある様子 |
|---|
 |
この3種類の圧縮ファイルだが、それぞれ役目がある。
| 3種類の圧縮ファイルの役目 |
|---|
 |
パッチの名前の部分に注目。
それぞれ赤い線を引いた部分が、パッチの役目を意味する所だ。
一番上は「I」でファームウェア(VMwareESXi本体)を意味する。
ごっそりと本体ごと入れ替える感じだ。
でも、VMwareESXi本体は、たった32MBの大きさな上、
パッチの大きさも47MBなので大した事はない。
真ん中の「T」は、VMwareToolsのパッチだ。
VMwareESXi本体のパッチを当てる際に、VMwareToolsも
新しいのを当てる必要が出てくる事もある。(不要な場合もある)
一番下の「U」は、VI Clientで監視画面のソフトのパッチだ。
|
それぞれの圧縮ソフトをLHAで解凍する。
| それぞれの圧縮ファイルを解凍した様子 |
|---|
 |
そしてVMwareESXi本体のパッチのフォルダーに移動する。
| VMwareESXi本体のパッチのフォルダーの中身 |
|---|
 |
桃色で囲んだ「remoteInstall.exe」ファイルが
パッチを当てるための実行ファイルだ。
だが。このまま実行ファイルを選んでも動かない。
DOSプロンプトの画面で操作する必要がある。
|
| DOSプロンプトの画面でパッチを当てる作業 |
|---|
>remoteInstall -h ホスト名 -u ユーザー名 -p パスワード
|
|
remoteInstallコマンドは上のような使い方をする。
|
もちろん、VMwareESXiが稼働中にパッチを当てる事ができる。
VMwareESXi本体のパッチを当てる事に成功した。
VMwareToolsと、VI Clientのパッチも当てた。
そして、VMwareESXi本体に当てたパッチの結果を反映させるために
サーバーの再起動を行った。
そしてバージョン情報を見てみる。
| パッチを当てた後のバージョン情報 |
|---|
 |
「VMware ESX Server 3i, 3.5.0 , 158874」
青い数字に注目する。
パッチを当てる前は「153875」だったが、パッチを当てた事で数字が
「158874」に増加している事がわかる。
|
VMwareToolsについては、パッチを当てただけではダメなのだ。
各仮想OSで、VMwareToolsを呼び出して、更新作業が必要になる。
VMwareESXiは改造Linuxなのか?
ネットなどを見ていると次のような記述を見かけた。
VMwareESXiはLinuxをベースだと誤解されやすい
そうだと思う。
なぜなら、私自身・・・
VMwareESXiはLinuxを改造した物だと思っていたのらー!!
さて、何故、こんな誤解をしてしまったのか。
T605サーバーにVMwareESXiのインストール失敗に遡る。
インストールの途中で、動かなくなった際の画面表示だった。
| エラー画面の様子 |
|---|
 |
ピンクの部分は以下のように書かれている。
「Loading module sata_svw ...」
sata_svwモジュールの取り込み途中で、コケている事がわかる。
|
さて、sata_svwモジュールだが、Linuxのモジュールに
あるのではないかと考えた。
そこでLinuxのモジュールに該当の物があるかどうかを見てみると
該当らしき物があったのらー!!
| CentOS5.1(Linux-2.6.18)のsata_svwモジュール |
|---|
[suga@linux]$ pwd
/lib/modules/2.6.18-53.el5/kernel/drivers/ata
[suga@linux]$ ls
ahci.ko pata_sis.ko sata_promise.ko sata_svw.ko
ata_piix.ko pdc_adma.ko sata_qstor.ko sata_sx4.ko
libata.ko sata_inic162x.ko sata_sil.ko sata_uli.ko
pata_marvell.ko sata_mv.ko sata_sil24.ko sata_via.ko
pata_pdc2027x.ko sata_nv.ko sata_sis.ko sata_vsc.ko
[suga@linux]$
|
|
青い部分がsata_svwモジュールだ。
|
この時、VMwareESXiはLinuxを改造したものではないかと思った。
| VMwareESXiはLinuxを改造したものではないかと思った |
|---|
 |
そして、私の頭の中で、この誤解の連鎖反応は続いた。
デルのT605サーバーの場合、VMwareESXiのイメージファイルである
VMware-VMvisor-InstallerCD-3.5.0_Update_3-123629.i386.isoを
CD-ROMに焼いた場合、CD-ROMでインストールができないため、
USBからVMwareESXiを起動させる方法を試してみる事になった。
まずはVMwareESXiのイメージファイルの中身を取り出す作業を行う。
| VMwareESXiのイメージファイルをマウント |
|---|
[root@vmware]# ls
VMware-VMvisor-InstallerCD-3.5.0_Update_3-123629.i386.iso image
[root@vmware]# mount -o loop /home/suga/tmp/VMware-VMvisor-InstallerCD-3.5.0_Update_3-123629.i386.iso image
[root@vmware]#
|
マウントに成功した。
imegeディレクトリに入ると、イメージファイルの中身が見れる。
そこで、イメージファイルの中身を見てみる事にした。
| VMwareESXiのイメージファイルの中身を見る |
|---|
[root@vmware]# ls
VMware-VMvisor-InstallerCD-3.5.0_Update_3-123629.i386.iso image
[root@vmware]# cd image
[root@vmware]# ls
binmod.tgz ienviron.tgz isolinux.cfg menu.c32
boot.catalog install.tgz license.tgz oem.tgz
cim.tgz isolinux.bin mboot.c32 vmkernel.gz
[root@vmware]#
|
赤と青の部分に注目すると「linux」の文字があるのがわかる。
Linuxに関するファイルである事が想像できる。
|
linuxという文字を見たため・・・
VMwareESXiは改造Linuxなのだ!
と誤解を深めていった。
もっと誤解をする事態になった。
それは「binmod.tgz」を展開して、その後で中身を見た時だった。
| binmod.tgzを展開 |
|---|
[suga@vmware]$ tar xvfz binmod.tgz
bin/
bin/ps
bin/vmware
bin/vmx
bin/vim-cmd
bin/vmware-vimdump
(途中、省略)
usr/libexec/
usr/libexec/pci-info
[suga@vmware]$
|
| binディレクトリを見る |
[suga@vmware]$ cd sbin
[suga@vmware]$ ls
authd esxcfg-mpath hostd vmkiscsi-tool
bootOption esxcfg-nas hwclock vmkiscsi-util
dcui esxcfg-nics hwinfo vmkiscsid
esxcfg-advcfg esxcfg-rescan lspci vmkload_mod
esxcfg-dhcp esxcfg-resgrp pidof vmklogger
esxcfg-dumppart esxcfg-route scantools vmkperf
esxcfg-hwiscsi esxcfg-swiscsi vm-support vmkping
esxcfg-info esxcfg-vmhbadevs vmdumper vmksystemswap
esxcfg-init-eesx esxcfg-vmknic vmkdump vmkvsitools
esxcfg-locker esxcfg-vswitch vmkerrcode vsi_traverse
esxcfg-loglevel esxtop vmkfstools vsish
esxcfg-module esxupdate vmkgdbd watchdog.sh
[suga@vmware]$
|
| lddで共有ライブラリを見る |
[suga@vmware]$ ldd vmkdump
linux-gate.so.1 => (0x0056f000)
libvmksysinfo.so => not found
libc.so.6 => /lib/libc.so.6 (0x008ae000)
/lib/ld-linux.so.2 (0x0088c000)
[suga@vmware]$
|
赤い部分は「linux」という文字がある。
Linux関連のライブラリだというのがわかる。
|
なので、ますます・・・
VMwareESXiってLinuxやん!
と誤解を深めていった。
だが、ネットで色々検索していると
VMwareESXiをLinuxベースと誤解されやすい
という文言を見つけた。
そして、ふと冷静になった。
よく考えると、もし、VMwareESXiが改造Linuxだったら
ソース公開の義務が発生するはず!
そうなのだ。
もし、改造Linuxを使っていたら、GPLのため、公開要求があれば
大事な部分を公開する義務が発生する。
VMwareESXiの本体を公開する事は、ヴイエムウェア社の
企業機密を公開する事を意味する。
いくらなんでも、そこまで太っ腹とは思えない。
という事は、次の2つの事が考えられる。
| インストーラーがLinuxではないか? |
|---|
 |
VMwareESXiをインストールするためのソフトが
Linuxを改造した物だと思った。
Linuxを使う事で、安価で、かつ、幅広いハードウェアに
対応しているという可能性はあると思う。
|
そして、もう1つは、VMwareESXiの起動の際の
起動支援ソフトかもしれない。
| VMwareESXiの起動支援ソフトがLinuxなのでは? |
|---|
 |
サーバーの起動時、BIOSからプログラムを読み込み
基本的なハードウェアを認識させてから
ハードディスクなどからOSを読み込む。
もしかして、BIOSのプログラムがOSを読み込む際、
VMwareESXiではなく、改造Linuxを読み込んでから
改造LinuxがVMwareESXiを起動させているのではないかと思った。
|
それとも、VMwareESXiの稼働中に、補助機能として
改造Linuxが動いている可能性も考えられる。
実際の所、仕組みまで勉強していないので推測の域を越えない。
でも、私は、この程度で良いのだ。
だって、事務員だもーん (^^)V
と逃げようと思ったが、ここで少し踏み止まって調べないと
ツッコミが来そうだ。
そこで、多少は悪あがきをする事にした。
調べてみると、ヴイエムウェア社のホームページに
VMwareESXiに関するプログラムで、ソースコードを
公開している物があるのを発見した。
ダウンロードサイト「VMware Open Source」
http://www.vmware.com/download/open_source.html
早速、「VMware ESXi 3.5, VI Client and VM Tools」を
ダウンロードする。
2009年6月21日時点での最新バージョンのVersion 3.5 Update 4だ。
何か手がかりが掴めるのではないかと思いダウンロードした。
ダウンロードした物はtar.gz形式なので展開する。
| 展開してみた |
|---|
[suga@server]$ tar xvfz VMware-eesx-public-source-3.5.0-153875.tar.gz
VMware-esx-drivers-public-source-3.5.0-153875.tar.gz
VMware-esx-server-public-source-3.5.0-153875.tar.gz
VMware-eesx-gpl-public-source-3.5.0-153875.tar.gz
[suga@server]$
|
3種類のtar.gz形式のファイルが出てきた。
VMware-esx-server-public-source-3.5.0-153875.tar.gzの
ファイルがVMwareESXi本体に関連した部分に思えた。
そこで展開してみる。
| VMware-esx-server-public-source-3.5.0-153875.tar.gzを展開 |
|---|
[suga@server]$ tar xvfz VMware-esx-server-public-source-3.5.0-153875.tar.gz
VMware-esx-public-source-3.5.0-153875/
VMware-esx-public-source-3.5.0-153875/vmklinux/
VMware-esx-public-source-3.5.0-153875/vmklinux/linux_block.c
VMware-esx-public-source-3.5.0-153875/vmklinux/linux_char.c
VMware-esx-public-source-3.5.0-153875/vmklinux/linux_ctype.c
VMware-esx-public-source-3.5.0-153875/vmklinux/linux_inet.c
VMware-esx-public-source-3.5.0-153875/vmklinux/linux_ioat.c
VMware-esx-public-source-3.5.0-153875/vmklinux/linux_net.c
VMware-esx-public-source-3.5.0-153875/vmklinux/linux_pci.c
(途中、省略)
VMware-esx-public-source-3.5.0-153875/installer/anaconda-9.1-pixmaps/windows-file-server.png
VMware-esx-public-source-3.5.0-153875/installer/anaconda-9.1-pixmaps/workstation.png
VMware-esx-public-source-3.5.0-153875/installer/anaconda-9.1-pixmaps/x-window-system.png
VMware-esx-public-source-3.5.0-153875/uwglibc-2.3.3/
VMware-esx-public-source-3.5.0-153875/uwglibc-2.3.3/uwglibc-2.3.3.tar.gz
VMware-esx-public-source-3.5.0-153875/scripts/
VMware-esx-public-source-3.5.0-153875/scripts/mkinitrd.sh
VMware-esx-public-source-3.5.0-153875/README
VMware-esx-public-source-3.5.0-153875/COPYING
[suga@server]$
|
そして展開された中身を見るため、作成されたディレクトリに移動してみる。
| 展開された中身を見てみる |
|---|
[suga@server]$ cd VMware-esx-public-source-3.5.0-153875/
[suga@server]$ ls
COPYING include ramcheck uwglibc-2.3.3 vmklinux
README installer scripts vmkiscsid vmkload_mod
[suga@server]$
|
赤い部分は、VMwareESXiのインストールを行うための
プログラム・インストーラーのソースが格納されているようだ。
|
そこで上の青い文字で表しているREADMEファイルの中身を見てみる。
| READMEの中身を見てみる |
|---|
Included is the source for the following packages:
1) VMware ESX Server installer (installer/)
Modified version of anaconda-9.1
2) vmklinux
Based on 2.2 and 2.4 linux kernel code
3) vmkload_mod
Based on insmod source from the modutils package
4) uwglibc-2.3.3
Based on glibc-2.3.3 source.
5) ramcheck
Based on memtest86.
You must be running RHEL 3, with gcc 3.2.3 installed, to compile
these packages. See README files located in the subdirectories for
descriptions and compilation instructions.
Unless explicitly stated otherwise, all of the files in this package are
distributed under the GNU General Public License - see the accompanying
COPYING file for more details.
|
うーん、ESXに関するプログラムが格納されたディレクトリ群のようだ。
基本的にESXとESXiの仕組みは一緒なので、共通して使える部分だと思う。
installディレクトリは、どうやらVMwareESX(ESXi)をインストールする
補助プログラムを格納している部分だ。
だが、vmklinuxは、Linuxのカーネルのソースコードだ。
ESXの場合、RHEL3を土台としたコンソールプログラムがあるから
そのための物だと思われる。
ご丁寧(?)にglibcも付属している。
|
ファイル名などを眺めながら、どんな役割のプログラムなのかを
想像してみたりすると、VMwareESX(ESXi)のインストールから
運用を行うための周辺プログラムを、オープンソースとして
公開しているようだ。
v
まぁ、GPLやLGPLのプログラムを含んでいるため
ソースの公開義務がある上に、反対に周辺部分を公開する事で
不特定多数の人が改良を行ったり、周辺ソフトの開発を行う際に
既に出ているオープンソースを改造して使う事で
開発期間の短縮や費用の削減も考えられる。
まとめ
何も考えずに、仮想化サーバーを使っていると思わぬ所で
性能劣化があったり、仮想OSのインストールができなかったりした。
仮想CPU、仮想メモリの割り当て。
結構、書いたつもりですが、まだまだ私の知らない事の方が多いので
色々出てきた時は、続編を書きたいと思います。
次章:「ヤマハYMS-VPN1で安価でVPN通信」を読む
前章:「シンクライアントの構築と試験導入」を読む
目次:システム奮闘記に戻る