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が優先される構成だが、ユーザが指定したバイナリ変換が選択されたことを示す。
Apr 22 18:56:07.363: vmx| MONITOR MODE: allowed modes : BT HV HWMMU
Apr 22 18:56:07.363: vmx| MONITOR MODE: user requested modes : BT
Apr 22 18:56:07.363: vmx| MONITOR MODE: guestOS preferred modes: HWMMU HV BT
Apr 22 18:56:07.363: vmx| MONITOR MODE: filtered list : BT
Apr 22 18:56:07.363: vmx| Msg_Hint: msg.cpuid.LMwithBT (sent)
Apr 22 18:56:07.363: vmx| Software virtualization is incompatible with long mode on Intel EM64T CPUs. Virtual execution will begin in software mode, but will automatically switch to hardware mode if the guest enters long mode.
なお、最後に書かれているように、仮想マシンの設定で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)を使う場合には利用されている。
