Unofficial Tech Memo - Koji Komatsu

無償版ESXiでのRemote CLIの利用制限

kkomatsu — Wed, 29 Jul 2009 13:41:47 GMT

下記のKBに記載されているように、無償版ライセンスのESXiでは、Remote CLI (現 vSphere CLI) のコマンドによる一元管理は、Read Onlyの操作のみが使用許可されている。

VMware ESX and ESXi 3.5 Comparison
http://kb.vmware.com/kb/1006543

今までこの制限は紳士協定で、機能的には動いてしまっていたが、3.5 Update4では実際に機能的な制限をかけはじめている模様。

http://communities.vmware.com/thread/203414
http://communities.vmware.com/message/1213115

2009年10月29日追記

ESX / ESXi 4.0について新しいKBがでていた

VMware ESX and ESXi 4.0 Comparison
http://kb.vmware.com/kb/1015000

仮想マシンのモニターモード(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)を使う場合には利用されている。

VMware Toolsでの一括アップデートをゲスト再起動なしで実施する

kkomatsu — Wed, 08 Apr 2009 14:15:27 GMT

VI Toolkit for Windows (通称VI PowerShell)には、Update-Toolsというコマンドレットがある。これはゲストOSにインストールされたVMware Toolsをアップデートするためのもの。ただし、Toolsアップグレード後に自動的にゲストOSの再起動がかかってしまう。こういった場合にはGet-Viewを使うのが定石。Pabloがコミュニティでのディスカッションを紹介している。

Installing VMware Tools without a reboot ...
http://communities.vmware.com/blogs/DeveloperCenter/2008/12/30/installing-vmware-tools-without-a-reboot-

How to install VMware tools without a reboot?
http://communities.vmware.com/thread/168530

結論的には下記のように書くのがベストプラクティスのようだ。(Windowsゲスト限定)

$insParm = '/s /v"/qn /norestart"'
$updList = Get-VM | Where-Object {$_.PowerState -eq "PoweredON"} | % {Get-View $_.ID} | Where-Object {$_.guest.toolsstatus -match "toolsOld" } | Where-Object {$_.guest.guestfamily -match "windowsGuest"}
foreach ($uVM in $updList) {
    $uVM.Name
    $uVM.UpgradeTools_Task($insParm)
    #Wait 30 seconds before starting another update task
    Start-Sleep -s 30
}

ポイントはToolsのアップグレードをサイレントかつ自動再起動なしで実施するパラメータを指定していること。もちろん、ゲストを再起動する必要性そのものがなくなるわけではないので、一括アップグレード後に、必要な順序で管理者が再起動をかけていくことになる。再起動されるまでも、VI Clientには、ToolsのバージョンがOKと出てしまうので、どれが最新かどうか分からなくならないように注意も必要。

なお、日本語ゲストOSの場合でToolsのアップグレードがエラーでとまってしまう問題は、ESX3.5 Update4で解消されている。したがって、日本語環境ではそれ以降のバージョンであることが前提。

ESX3.5 Update4 Release Notes
http://www.vmware.com/support/vi3/doc/vi3_esx35u4_rel_notes.html

2009年11月23日追記

vSphere PowerCLI 4.0 Update1 で Update-Tools コマンドレットが拡張され、-Noreboot オプションをつけるだけで上記と同じことができるようになった。詳細は下記の PowerCLI Cmdlets References を参照。
http://www.vmware.com/support/developer/windowstoolkit/wintk40u1/html/Update-Tools.html

仮想マシン・仮想ディスク単位での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フォーマットで保存することができる。

LinuxゲストOS上でタイマー割り込みの回数を確認する

kkomatsu — Sat, 17 Jan 2009 15:15:39 GMT

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）

#define HZ 100

もしくは、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になっていることがわかる。

--root@localhost ~--# /sbin/hwclock
Sat 03 Jan 2009 05:57:12 PM JST -0.686850 seconds
--root@localhost ~--# date
Sat Jan 3 17:57:12 JST 2009
--root@localhost ~--# cat /proc/interrupts
CPU0
0: 262551 IO-APIC-edge timer
1: 475 IO-APIC-edge i8042
6: 5 IO-APIC-edge floppy
7: 0 IO-APIC-edge parport0
8: 6 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
12: 7455 IO-APIC-edge i8042
14: 24515 IO-APIC-edge ide0
169: 9294 IO-APIC-level ioc0
177: 1891 IO-APIC-level vmxnet ether
NMI: 0
LOC: 262605
ERR: 0
MIS: 0
--root@localhost ~--# sleep 10
--root@localhost ~--# cat /proc/interrupts
CPU0
0: 263557 IO-APIC-edge timer
1: 475 IO-APIC-edge i8042
6: 5 IO-APIC-edge floppy
7: 0 IO-APIC-edge parport0
8: 6 IO-APIC-edge rtc
9: 0 IO-APIC-level acpi
12: 7455 IO-APIC-edge i8042
14: 24610 IO-APIC-edge ide0
169: 9306 IO-APIC-level ioc0
177: 1957 IO-APIC-level vmxnet ether
NMI: 0
LOC: 263609
ERR: 0
MIS: 0
--root@localhost ~--# date
Sat Jan 3 17:57:22 JST 2009
--root@localhost ~--# /sbin/hwclock
Sat 03 Jan 2009 05:57:23 PM JST -0.913159 seconds

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

Interpreting esxtop Statistics

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

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

Interpreting esxtop Statistics

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

VCのIPアドレス変更後、ESXが「応答なし」になる

kkomatsu — Fri, 26 Dec 2008 17:25:36 GMT

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系)