Unofficial Tech Memo - Koji Komatsu

仮想マシンのモニターモード(VMMの実行モード)を確認する

kkomatsu — Sun, 26 Jul 2009 12:56:49 GMT

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)を使う場合には利用されている。

パフォーマンス概要チャート (Performance Overview Charts)

kkomatsu — Wed, 11 Mar 2009 07:22:45 GMT

vCenter 2.5 Update4 から、パフォーマンス概要を一覧化する「パフォーマンス概要チャート (Performance Overview Chart)」機能が追加されている。ESX単位で複数の仮想マシンのパフォーマンスグラフを並べて表示する新しい画面が追加されただけで、今まで見えなかったものが見えるようになるわけではない。ただ、仮想マシン数が非常に多い環境では役立つ機会もあるかもしれない。

VMware VirtualCenter 2.5 Update 4 リリースノート
http://www.vmware.com/jp/support/vi3/doc/vi3_vc25u4_rel_notes_ja.html

パフォーマンス概要チャート： VirtualCenter 2.5 Update 4 では、パフォーマンス概要プラグインが導入されました。これは、CPU、メモリ、ディスク、ネットワークといった主要なパフォーマンスメトリックが 1 つのビューに表示され、複数のチャートを切り替える必要がありません。

vCenterのインストーラだけでは構成することができないので少々面倒くさい。詳細は下記のKBにまとまっている。

Installing the Performance Overview Plug-In in VirtualCenter 2.5 Update 4 and above
http://kb.vmware.com/kb/1008296

画面のイメージを添付しておく。
ホスト、プール、VMを選択した場合に、新しいタブが選択できる。クラスタやデータセンタではタブは現れない。

2009年10月29日追記

vSphere4ではこの概要チャートは標準機能として実装されている。
また、KBの名称に above が追加されたので修正した。

仮想マシン・仮想ディスク単位でのI/O遅延を確認する

kkomatsu — Fri, 23 Jan 2009 03:15:18 GMT

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

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

/usr/lib/vmware/bin/vscsiStats -l

出力例

Virtual Machine worldGroupID: 1632, Virtual Machine Display Name: vmname {
Virtual SCSI Disk handleID: 8397
}

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

統計情報の収集開始

/usr/lib/vmware/bin/vscsiStats -i 8397 -w 1632 -s

統計情報の表示

/usr/lib/vmware/bin/vscsiStats -i 8397 -w 1632 -p latency

統計情報の収集終了

/usr/lib/vmware/bin/vscsiStats -i 8397 -w 1632 -x

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

Histogram: latency of IOs in Microseconds (us) for virtual machine worldGroupID : 1632, virtual disk handleID : 8397 {
min : 491
max : 14161
mean : 4582
count : 27
{
0 (<= 1)
0 (<= 10)
0 (<= 100)
1 (<= 500)
0 (<= 1000)
23 (<= 5000)
3 (<= 15000)
0 (<= 30000)
0 (<= 50000)
0 (<= 100000)
0 (> 100000)
}
}

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

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

esxtopバッチモードの出力をperfmonでグラフ表示する

kkomatsu — Sun, 18 Jan 2009 06:46:59 GMT

esxtopバッチモード

esxtopはESXのサービスコンソールで使用可能なパフォーマンス情報を表示するコマンド。ESXiの場合、Remote CLIやVIMAの仮想アプライアンスでresxtopとして同等のコマンドが用意されている。位置づけとしては通常時の継続的なパフォーマンス監視というよりは調査目的であるため、対話モードで使用することが一般的だが、バッチモードを使用するとパフォーマンス情報が標準出力にcsvフォーマットで出力されるため、ファイルにリダイレクトして別用途で使用することができる。
(VI Clientではパフォーマンスチャートの内容をMS Excelフォーマットで保存することができる。)

バッチモードを使用する一般的な手順

手っ取り早く使うには、下記のコマンドを使用する

esxtop -b -a -n 1 > esxtop_output.csv

-bがバッチモードを指定している。-aは全項目を出力することを示している。-nは表示する統計回数である。-nを省略した場合、適当なタイミングでCtrl-Cを押せばよい。

さて、全項目を出力するとデータ量が大きくなりがちなので、通常は項目を指定しておく。esxtopを対話モードで使用し、c/m/d/nキーなどで使用する画面を選択し、fキーで項目を選択した後、Wキーで設定を保存する。バッチモードでこの設定を指定することで、取り出したいデータだけを対象とすることができるのである。
なお、設定ファイルは複数つくることができるので、パターンを複数用意することも可能。例えば下記のようになる。

esxtop -b -c .esxtop_any_config -n 1000 > esxtop_output.csv

なお、esxtopの項目の説明については、マニュアル「リソース管理ガイド」やInterpreting esxtop Statisticsを参照されたい。

パフォーマンスモニタ(perfmon)での表示

バッチモードで書き出したcsvファイルは如何様にも使用できるが、グラフィカルなグラフにしたいなら、Windowsのパフォーマンスモニタ(perfmon)を使用することもできる。
手順は下記のとおり。

１．パフォーマンスモニタを立ち上げる（perfmonコマンド）
２．グラフを右クリックし、ドロップダウンリストから「プロパティ」を選択
３．開いた画面で「ソース」タブに切り替え
４．データソースセクションで「ログファイル」ラジオボタンを選択
５．「追加」ボタンをクリックし、esxtopのcsvファイルを選択
６．「OK」ボタンをクリックして画面を閉じる
７．再度グラフを右クリックし「カラムの追加」を選択
８．「次のコンピュータからカウンタを選ぶ」で、esxtopを取得したホストが選択されていることを確認し、表示したい項目を選択し「追加」する
９．必要な項目の追加が終わったら「閉じる」ボタンで画面に戻る

補足

VI Clientではパフォーマンスチャートの内容をMS Excelフォーマットで保存することができる。

Interpreting esxtop Statistics

kkomatsu — Thu, 08 Jan 2009 17:33:10 GMT

マニュアルだけではわからないesxtopの項目の解説。

Interpreting esxtop Statistics

ESX4.0での情報も一部記載されている。interrupts(割り込み)の統計画面も追加されるようだ。