VMware Communities > Blogs > Unofficial Tech Memo - Koji Komatsu > Tags

Blog Posts

Unofficial Tech Memo - Koji Komatsu

4 Posts tagged with the windows tag
0

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

0 Comments Permalink
0

LinuxゲストOSでの時刻同期

LinuxゲストOSでは、Kernelのバージョンによって時刻のずれを避けるための考慮が必要だったりする。最も一般的な設定としては、下記の3つ。

1.VMware Toolsの時刻同期機能を有効にする
これはESX3.5であれば、VI Clientで仮想マシンの設定項目に存在する「ホストとゲスト時間を同期」にチェックを入れるか、VMware Toolsの設定画面で有効にする。

2.grub.confでタイマーデバイス選択を制御する
かつては何を書くかで議論が絶えなかったが、今は下記の表であてはまるものをとりあえず盲目的に書いておく。
http://kb.vmware.com/kb/1006427

3.タイマー割り込みの回数を少なくする (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)であれば、2の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に変更して再コンパイルする。

タイマー割り込みの回数を確認する

さて、3の設定が効いているかどうかを確認する方法。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という項目があるので、こちらで同様の計算ができるが、タイマー割り込みの回数だけを抜き出す方法は不明。

0 Comments Permalink
0

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

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

メモ
set devmgr_show_nonpresent_devices=1
start devmgmt.msc

0 Comments 0 References Permalink
0

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

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

0 Comments 0 References Permalink
Click to view kkomatsu's profile

kkomatsu

Member since: Jul 29, 2007

このblogは小松康二の個人的なメモですのでサポート外の設定や勘違い等が含まれている可能性があります

View kkomatsu's profile