Unofficial Tech Memo - Koji Komatsu

vSphere PowerCLIとvSphere SDK for .Netの関係

kkomatsu — Thu, 29 Oct 2009 04:48:26 GMT

VI PowerShell / vSphere PowerCLI についてよく聞かれる質問のひとつが、VI Perl Toolkit / vSphere SDK for Perlに比べてできることが少ないのではないかという点。これはある意味正しい。というのも、PowerShell版は簡単に使える代わりに抽象化度が高く、本来のAPIに含まれる機能についての網羅性に欠けているのだ。

ただ、PowerCLIの範囲ではできないことも、.Net上に実装されVI PowerShellのバックグラウンドで透過的に動いているSDK for .Netを直接利用することで、制約をうけずより広範な処理を記述できる。もちろん PowerCLI の範囲ですむ部分はそこですましながら必要に応じてスクリプトの中で使い分けられるのだ。

この切り替えは、主にGet-Viewというコマンドレットを使って行う。Get-ViewにのIdを渡す(オブジェクトそのもののパイプライン渡しも可)と、純然たるManaged Objectが得られる。あとは、vSphere APIに実装されているプロパティやメソッドが自由に使えるようになる。

たとえば、vSphere PowerCLIのMove-VMコマンドの制約についてまとめた下記の記事も、Get-Viewを使うことで回避することができる。
Move-VMコマンドレットでのVMotionのクセ

下記の例では、指定したESX上のパワーオン状態の仮想マシンを全て別のESXにVMotionさせている。

$src_esx = Get-VMHost <esx-name1>
$dst_esx = Get-VMHost <esx-name2>
$VMs = Get-VM -Location $src_esx
$res = Get-ResourcePool 'リソース' -Location $dst_esx

$esx_moref = ($dst_esx | Get-View).Moref
$res_moref = ($res | Get-View).Moref

$VMs | Where-Object { $_.PowerState -eq "PoweredOn" } | foreach {
($_ | Get-View).MigrateVM($res_moref, $esx_moref, "highPriority", "PoweredOn")
}

PowerCLIの範囲をはみ出しているということを意識しなくてもよいくらいシームレスに使えてることが分かる。
ここで使われているMigrateVMはvSphere APIのメソッドであり、Move-VMはMigrateVMを透過的に使用しているPowerShellのコマンドレットなのだ。

最後に、SDK for .Netについて特徴をいくつか細くしておく。

メソッドに()を使う(PowerCLIのコマンドレットでは()は不要)
引数にオブジェクトを使う場合Morefを使う(PowerCLIはオブジェクトそのものかIdをとる)
MigrateVMとMigrateVM_Taskの違いはPowerCLIの-Asyncの有無に相当(非同期実行)
Get-Viewの逆はGet-ViObjectByViewで行う

このあたりを先日のVMware Virtualization Forum 2009のセッションでしゃべった資料は下記。
VMware Virtualization Forum 2009 A66資料

無償版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:18 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

パフォーマンス概要チャート (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 が追加されたので修正した。

VMware vCenter Server 2.5 on Linux Technology Preview

kkomatsu — Fri, 27 Feb 2009 15:33:49 GMT

VMware vCenter Server 2.5 on LinuxのTechnology Preview版が公開され、下記からダウンロード可能になっている。
http://communities.vmware.com/community/beta/vcserver_linux

CentOS 5.0 ベースの仮想アプライアンスとして提供されている。build番号は147989。
上記URLからダウンロード可能なインストールガイドを見る限り、機能的な制約はすでにかなり減っているようだ。気になる制約として残っているものは下記あたり。
・ゲストのカスタマイズ機能（クローン、テンプレートからデプロイ時）
・トポロジーマップ
・スケジュールタスク
・LDAPによる外部認証

将来については未定だが、このバージョンではDBとしてはOracle 10以降のみがサポートされている。また、Express Edition等が同梱されているわけではないので、別途構築する必要がある。

VI Toolkit for Windows 1.5 リリース

kkomatsu — Fri, 30 Jan 2009 08:25:41 GMT

VI PowerShell 1.5 (正式名称 VI Toolkit for Windows 1.5) がリリースされた。
32の新しいコマンドレットと多数のオプションが追加されており、Get-Viewを使わなくても設定の確認や変更ができる範囲が広がった。

詳細はリリースノートを。

VMware Infrastructure Toolkit (for Windows) 1.5 Release Notes
http://www.vmware.com/support/developer/windowstoolkit/wintk15/windowstoolkit15-200901-releasenotes.html

VI APIでデータストアブラウザ

kkomatsu — Fri, 23 Jan 2009 17:00:02 GMT

VI API経由では、データストアブラウザで行うような、VMFS上のファイル操作はできないと間違った情報をいろんなところで流してしまった。HostDatastoreBrowserを使うと、lsやrm相当の操作くらいはできるらしい。

HostDatastoreBrowser
http://pubs.vmware.com/vi-sdk/visdk250/ReferenceGuide/vim.host.DatastoreBrowser.html

そして、求めていたスクリプトを発見。インベントリに存在せずファイルとしてただ放置された状態の仮想マシンのリストを作成するVI PowerShellスクリプト。

Find Orphaned VMDK's

必見。

仮想マシン・仮想ディスク単位での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の確認方法が不明。

ゲストOS内でVMware ToolsやCustomizationのログを書き出す

kkomatsu — Sun, 18 Jan 2009 07:49:08 GMT

VMware ToolsはゲストOSにインストールすることが推奨されるコンポーネント。ドライバとシンプルなソフトウェア群でできていて日ごろはその動作を気にすることはないのだが、検証目的で機能の動作を確認したい場合、動作ログをとることが可能。

WindowsゲストのToolsログ

Windowsのバージョンにもよるが、下記にToolsの設定ファイルがある。

Windows 2003/XPでは、
C:\Documents and Settings\All Users\Application Data\VMware\VMware Tools\tools.conf

Windows 2008/Vistaでは、
C:\Users\All Users\VMware\VMware Tools\tools.conf
もしくは
C:\ProgramData\VMware\VMware Tools\tools.conf

ここに下記を記述する。
log = "TRUE"
log.file = "%PATHNAME%"

ただし、VCBでVSS(Volume Shadow Copy Service)を利用している場合、ログを有効にしているとエラーが発生してしまうらしい(下記はESX3.5 Update2とVCB1.5、Windows2003のケース)。

2008-10-07 18:55:24.789 'vcbMounter' 1544 error Error: Other error encountered: Snapshot creation failed: Could not quiesce file system.

2009年10月29日追記

少々敷居は高いが、VSSを使用する場合DebugViewを使えば問題ないようだ。詳細は下記KBに。

Enabling debug logging for VMware Tools within a Windows guest operating system
http://kb.vmware.com/kb/1007873

冒頭の一般的な方法もKBになっていた。

Collecting diagnostic information for VMware Tools
http://kb.vmware.com/kb/1010744

LinuxゲストのToolsログ

記述内容はWindowsゲストと同様。設定ファイルは下記にある。
/etc/vmware-tools/tools.conf

なお、デフォルトで下記にすこしだけログが記録されている。
/var/log/vmware-tools-guestd

また、上記とは別に、クローンの際のカスタマイゼーションのログもゲストOS内で確認できる。

Windowsゲストのカスタマイゼーションログ

sysprepに関するログが、C:\WINDOWS\Temp\vmware-imcの下にあるguestcust.logとtoolsDeployPkg.logに書き出される。

Linuxゲストのカスタマイゼーションログ

エラー等が発生すると、/var/log/vmware/customization.logに記録が残っている。

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(割り込み)の統計画面も追加されるようだ。

P2Vで自動的に無効になったデバイスを表示・削除する

kkomatsu — Fri, 02 Jan 2009 13:55:05 GMT

必須ではないが、P2V後のプラグアンドプレイによるハードウェアの更新後も古いドライバによる悪影響が疑われる場合には下記で紹介されている手法が使える。

接続されていないデバイスの情報を表示させる
http://d.hatena.ne.jp/rasis/20081227/1230389439

メモ
set devmgr_show_nonpresent_devices=1
start devmgmt.msc

P2V後、古いネットワークアダプタとのIPアドレス重複エラーが発生する

kkomatsu — Sat, 27 Dec 2008 17:32:58 GMT

VMware ConverterでP2VしたWindows仮想マシンで、ネットワーク接続に物理環境と同じIPアドレスを割り当てようとすると、「このネットワークアダプタ用に入力されたIPアドレスは別のアダプタに既に割り当てられています。」というようなエラーメッセージが表示される場合がある。
ここで指摘されるネットワークアダプタは物理環境で認識していたもので、Windowsのプラグアンドプレイ機能によってP2V後の最初の起動の際にクリーンアップされるべきものだ。ところが、デバイスマネージャには表示されないものの、レジストリ上にゴミとして残ってしまいIPアドレスの競合を引き起こしてしまうことがある。

MSの下記KBがこの事象の詳細と対処方法を解説している。
http://support.microsoft.com/kb/269155/ja