Blog Posts

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

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

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

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

Find Orphaned VMDK's

必見。

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.

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に記録が残っている。

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）

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

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

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

メモ
set devmgr_show_nonpresent_devices=1
start devmgmt.msc

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

VI PowerShellのサンプルとしてよく見かける下記の記述では、どうやらCold Migrationしかできないようだ。VMotionしようとすると、inner errorと言われしまう。結構はまり所かも。

Move-VM -VM (Get-VM "vm-name") -Destination (Get-VMHost "host-name")

ホストの変わりにリソースプールを指定すれば成功するのだが、リソースプールではなくてESX直下にVMotionしたい場合、回りくどく下記のように書く必要がある。

Move-VM -VM (Get-VM "vm-name") -Destination (Get-Resourcepool -Name リソース -Location (Get-VMHost "host-name"))

途中、Get-Resourcepool で指定している「リソース」という名前は、ESXに自動的に生成された見えないルートリソースプールの名前。英語版の場合には「リソース」ではなく「Resource」となるのかな？（未確認）

なお、クラスタ内の場合、DRSの有無にかぎらずESXのルートリソースプールはクラスタのルートリソースプールになっているのか、コレで指定してもESXを移動しない。（エラーは発生せず、成功したように見えるが。）

これらの点について、VI PowerShellのヘルプでは下記のように注意書きされている。

Moving a virtual machine in a cluster is only possible if the virtual machine is in a resource pool in that cluster.

実際の挙動を確認した限りは下記が正解に近いのではないだろうか。

クラスタの有無にかかわらず、VMotionの移行先にはリソースプールだけが指定できます。また、クラスタ内では（たとえESXのルートリソースプールを指定したとしても）ESX間の移行はできません。

なお、確認は ESX3.0.3 / VC 2.0.3 および、ESX 3.5 Update1 / ESXi 3.5 Update1 / VC 2.5 Update1 で実施した。