ESX3.xまでのCPU命令の処理

x86のサーバ仮想化においてCPU命令の大半は物理CPUに直接わたされるが、特権命令やセンシティブ命令は直接実行させず安全に処理する必要がある。その方式として、ハイパーバイザのソフトウェア処理のみで実現するバイナリ変換(Binary Translation)という方式、物理CPUの仮想化支援機能(Intel-VT/AMD-V)を使用する方式、ゲストOSをハイパーバイザと協調するようにあらかじめ書き換えるOS準仮想化(Paravirtualization)の3つの方式が存在する。これらはESXではVMM(Virtual Machine Monitor)の実行モードとも呼ばれる。

ESXはハイパーバイザとしてはバイナリ変換を実装する唯一の製品であり、かつ、バイナリ変換を主たる方式として採用してきた。

物理CPUによる仮想化支援のうち、CPUコマンドの処理を支援する機能はIntelではVT-xと呼んでいる。ESXがこれまでVT-xをほとんど利用してこなかった理由はいくつかあるが、主だった理由は下記の2つだ。

• 特権命令やセンシティブな命令を安全に処理するVMX Rootモードと、一般的なCPU命令を処理するVMX non-rootモードを切り替えるVMEnter/VMExitの際の遅延が大きい (VMCALL/VMRESUMEコマンドの遅延が大きい)
• モードの切り替えの際に、TLBを完全にフラッシュされてしまう

モードの変更はVT-xによるサーバ仮想化のまさに中核となる部分であり、これが遅いということは致命的だ。また、全ゲストOS上の処理についてTLBのミスヒット率が高まってしまう影響も甚大だ。要は、VT-xの初期技術は、サーバ仮想化を容易にする(ハイパーバイザで処理する内容が少なくてすむ)かわりに遅くなるという、従来からサーバ仮想化を安全に実現できていたESXからみるとほとんど魅力のない技術だったのだ。

ESX4でのCPU仮想化支援機能の利用

ところが、その後の開発でCPU支援機能も魅力的になってきた。

• VMCALL/VMRESUMEコマンドの処理が最適化され遅延が大幅に小さくなってきた
• Intel VPID(Virtual Processor ID)、AMD Tagged TLB によって、TLBのフラッシュが全仮想マシンに影響しなくなった
• Intel EPT(Extended Page Tables)、AMD RVI(Rapid Virtualization Indexing)によって、ページテーブル管理のオーバーヘッドの削減が利用できるようになった
• Intel FlexPriorityによる割り込み処理のオーバーヘッドの削減できるようになった

ただ、これらの魅力は物理CPUの世代に大きく依存する。Intelを例に挙げれば、FlexPriorityはPenryn以降で利用できるが、EPTやVPIDはNehalem以降で対応する。また、FlexPriorityはゲストOSによっても効果の程に違いがある。
そこで、ESX4は物理CPUの世代とゲストOSの種類に応じて、最も高速に動作すると期待される方式を、個々の仮想マシンの起動時に自動的に選択するようになった。この選択基準をまとめた表をdrummondsが下記に公開している。

ESX Monitor Modes

2009年10月29日追記 - 下記のテクニカルペーパーでvSphereでの実行モードの選択の詳細が正式公開されている
http://www.vmware.com/resources/techresources/10060

実に複雑に見えるが、おおよそ下記のように理解できる。(Intelの場合)
・EPTが利用できる場合は利用する。この際、VT-xは必須。
・上記以外では、45nm Core2 以降のCPUはモード切り替えの遅延が小さいためVT-xを使用する。
・上記以外ではバイナリ変換を利用する。
例外が多いが理由は様々だ。たとえば、レガシーなWindowsでは特権命令の一部にCPU命令の正しい使い方に沿っていないものがあり、バイナリ変換の際にその不具合を効率よく回避している。

さて、この選択だが手動で変更することも可能だ。
EPTやRVIはページテーブルの管理コストを削減するもので、メモリアクセスを高速化する技術ではない。ページテーブルの管理(プロセスの生成や動的なメモリ割り当て、コンテキストスイッチ)がほとんど発生しない環境で、TLBにヒットしない論理メモリアドレスへのアクセスが発生すると、物理CPUのMMUがシャドウページによって1段階でアクセスできる従来の方式の方が高速に動作するという例外的な環境もありえる。

このあたりの詳細はEPTやRVIを使用した場合のESXのパフォーマンスについて言及した下記資料が詳しい。
http://www.vmware.com/resources/techresources/10006
http://www.vmware.com/resources/techresources/1079

実際に利用されているMonitor Modeの確認

実際に手動で指定したMonitor Modeで仮想マシンが動作できるかは、物理CPUの世代等に依存する。最終的に、仮想マシン起動時にMonitor Modeとして何が選択されたかをみるには、データストア上のvmware.logを参照することになる。
http://www.vmware.com/resources/techresources/10036

一例を挙げると、下記の出力である。
BTはバイナリ変換、HVはCPUの仮想化支援、HWMMUはさらにETPもしくはRVIを使用するモードを示す。
allowed modesは使用可能なモードで、64bit ゲストOSはBTでは動作しないし、古いCPUではHWMMUは使用できないなどの判断が含まれている。user requested modesは手動で設定したモード、guestOS preferred modesは先のDOC-9882に記載されているデフォルトの優先順位であり、最後のfiltered listに、選択されたMonitor Modeが記載されている。
例では、本来VT-x + EPTが優先される構成だが、ユーザが指定したバイナリ変換が選択されたことを示す。

なお、最後に書かれているように、仮想マシンの設定で32bitゲストOSを指定しているのに、64bitゲストOSをインストールしてしまったような場合、上記でバイナリ変換が選択されても、64bitでのCPU命令が確認されたタイミングでバイナリ変換不能ということでモードが切り替わるケースがありえる。

(補足) ESX3.xまでのCPU仮想化支援機能の利用について

前述のTechnical Paper(10036)に詳細が記載されているが、ESX3.xも64bit OSをゲストOSとして使う場合など、バイナリ変換ではなくCPUの仮想化支援機能を利用してきた。
また、Intel FlexMigrationやAMD Extended Migrationは、CPU命令の仮想化としてVT-xやAMD-Vを利用していなくても利用できるため、ESX3.5でバイナリ変換を利用してる仮想マシンでも、EVC(Enhanced VMotion Compatibility)を使う場合には利用されている。

これもサポート外だと思うが、パフォーマンスの調査で有効かもしれない。
ESXでサービスコンソールにログインしてvscsiStatsコマンドを使用することで、仮想ディスク単位でI/O遅延を確認することができる。

まず、下記のコマンドを実行し、仮想マシンと仮想ディスクの識別IDを確認する。

出力例

上記のworldGroupID、handleIDを利用する。

統計情報の収集開始

統計情報の表示

統計情報の収集終了

統計情報の出力例。I/O遅延の分布や最小値、最大値なども確認できる。単位はmicro sec。

latency以外に、ioLength, seekDistance, outstandingIOs, interarrival が確認できる。
csvでの書き出し（-c オプション）もある。

ESX3.0.xでは、コマンドはあるものの -l オプションがないため、識別IDの確認方法が不明。

LinuxゲストOSでの時刻同期

LinuxゲストOSでは、Kernelのバージョンによって時刻のずれを避けるための考慮が必要だったりする。最も一般的な設定としては、下記の３つ。

１．VMware Toolsの時刻同期機能を有効にする
これはESX3.5であれば、VI Clientで仮想マシンの設定項目に存在する「ホストとゲスト時間を同期」にチェックを入れるか、VMware Toolsの設定画面で有効にする。

２．grub.confでタイマーデバイス選択を制御する
かつては何を書くかで議論が絶えなかったが、今は下記の表であてはまるものをとりあえず盲目的に書いておく。
http://kb.vmware.com/kb/1006427

３．タイマー割り込みの回数を少なくする (kernel2.6系のみ)
これが一番厄介だが効果は劇的だったりする。kernel2.6系では、カーネルコンパイル時のオプションに1秒間の割り込み回数が100,250,1000の3種類が選べる。Novel SLES10SP2では250になっているが、RHEL4やRHEL5は1000になっている。特にVirtual SMP構成の場合は、CPUの分だけLOCの割り込みが倍増するため影響が大きい。
REHL4.7、5.1以降(CentOSもOK)であれば、２のKBにも記載されているようにgrubのdivider=10だけでよい。
だが、それ以外についてはkernelのヘッダファイルを修正して再コンパイルする必要がある。
具体的には、/usr/src/linux-2.6/include/asm-i386/param.hのHZの定義を下記のように修正する。（詳細はhttp://kb.vmware.com/kb/1420）

もしくは、CONFIG_HZ_1000=yをCONFIG_HZ_100=yに変更して再コンパイルする。

タイマー割り込みの回数を確認する

さて、３の設定が効いているかどうかを確認する方法。dividerの設定は起動後に/proc/cmdlineでも確認できるが、割り込みの回数自体も/proc/interruptsで表示される累積の割り込み回数を何度か表示して、差分と経過時間から計算することができる。(SLES10SP2のように、ディストリビューションによっては最初から/proc/sys/kernel/HZに示されているケースもある。)

例えば、下記はdivider=10を指定したRHEL5.1で、10秒毎に/proc/interruptsの結果を表示した例。割り込みレベル0もしくはLOCの差を10で割ると、約100回の割り込みが発生したことがわかる。つまり、割り込み回数がデフォルトの1000から100になっていることがわかる。

なお、Windowsではperfmonでinterrupts/secという項目があるので、こちらで同様の計算ができるが、タイマー割り込みの回数だけを抜き出す方法は不明。

VCのIPアドレスを変更すると、管理下のESXは全て「応答なし(not responding)」になる。

VCとESXの接続状態の確認は、VCからのポーリングではなく、ESXから定期的(60秒毎？)に生きていることを通知するしくみになっている(VCはこの通信をudp/902で待ち受けている)。VCのIPアドレスが変更されてもESXには変更が通知されないため、ESXはこの設定ファイルに記録された古いIPアドレスに通知を送り続ける。VCはこの通知を受け取れず「応答なし」とみなしてしまうことになる。

このような状況になった場合、もっとも容易に復旧する方法は、
１．VI Clientのインベントリ画面でデータセンタを選択し、「ホスト」タブを開く
２．ShiftやControlボタンを使ってESXを複数選択する
３．右クリックし、まとめて「切断」する
４．ESXの切断が終わったら、同様に右クリックし、まとめて「接続」する

再度接続しなおすことで、ESXは新しいVCのIPアドレスを認識することになる。
切断中はVMware DRSといった機能は動作しないが、仮想マシンの動作そのものには一切影響しない。

VI Clientで複数選択ができないバージョンの場合、下記のスクリプトを使用することでESXを1台ごと切断・接続する手間を省くことができる。

VI Perl Toolkit Script to Reconnect Non-Responding Hosts
http://kb.vmware.com/kb/1003343

なお、ESXは自身を管理しているVCのIPアドレスを下記のファイルに記録している。
/etc/opt/vmware/vpxa/vpxa.cfg (VC2.5系)
/etc/vmware/vpxa.cfg (VC2.0系)