![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
VMware ESXサーバーでは、同種または異種のオペレーティング・システムの複数のインスタンスを1台のサーバー上で仮想マシンとして実行できるので、アプリケーション作業負荷の統合が単純かつ迅速にできます。しかし、どのように包括的な計画を立てたとしても、システムが障害を起こすことはあります。
トラブルシューティングを容易にするには、VMware ESXサーバーに障害が発生したときの問題を、障害の種類に応じていくつかに分類します。最も一般的な方法は、2行2列の表を作って、カテゴリーを4つに分類します。行にはサーバー問題と仮想マシン問題、列にはネットワークとストレージと書きます。
また、もうひとつの大きな潜在的問題領域としてMUI（Management User Interface：管理ユーザー・インターフェース）があり、しばしば問題を起こすことがあります。
障害が発生したときの最初の診断ステップは、診断データを集めることです。集めたデータを分析して、障害の原因を探ることができます。次のいくつかのセクションでは、データを集める方法、情報を探す場所、およびデータを解釈する方法について述べます。
最初に収集すべき重要なデータは、/usr/bin/vm-support スクリプトから生成された出力ファイルです。この作成ファイルはカレント・ディレクトリーに保存され、esx-XXXX-XX-XX.XXXX.tgzというファイル名です（Xは日付とプログラムID情報です。たとえば、esx-2005-01-04.27059.tgzなど）。
/usr/bin/vm-support スクリプトは、VMwareによって定期的に更新されています。最も正確な情報を収集するには、最新版をダウンロードしてインストールしてください。さらに、VirtualCenterに問題がある場合は、VirtualCenterログを収集する必要があります（この問題の診断は、この記事の範囲を超えています）。それぞれの最新版については、参考文献を参照してください。
データを収集したら、vm-support出力（バイナリ・モード）を適切なサポート担当者に送信して、診断してもらうことができます。Linuxベースのシステムでファイルを展開するには、次のコマンドを発行します。tar zxvf esx-XXXX-XX-XX.XXXX.tgz
システム全体を眺めて、システム上のハードウェアがどのように構成され、配置されているかを把握しましょう。このためには、コマンドライン・ユーティリティーを使用するか、/usr/bin/vm-support ファイルからの出力をチェックします。
/usr/bin/vm-support から出力されたtar圧縮ファイルを展開すると、以下のディレクトリーが含まれています。
リスト1. vm-support出力のレイアウト
etc/
proc/
root/
tmp/
usr/
var/
and possibly 'home' or 'vpx' depending on the location of the .vmx config files.
|
ESXサーバーのレイアウトの全体像を把握するには、tmpディレクトリーから始めてください。システム上のPCIバス・デバイスは、ファイルtmp/lspci.1.*.txtにあります。/sbin/lspciコマンドを実行すると、同じ出力を得ることができます。リスト2に、出力リストの例を示します。
リスト2. lspciからの出力
# /sbin/lspci
00:00.0 Host bridge: ServerWorks: Unknown device 0014 (rev 33)
00:00.1 Host bridge: ServerWorks: Unknown device 0014
00:00.2 Host bridge: ServerWorks: Unknown device 0014
00:01.0 VGA compatible controller: ATI Technologies Inc Radeon VE QY
00:0f.0 ISA bridge: ServerWorks: Unknown device 0203 (rev a0)
00:0f.1 IDE interface: ServerWorks: Unknown device 0213 (rev a0)
00:0f.2 USB Controller: ServerWorks: Unknown device 0221 (rev 05)
00:0f.3 Host bridge: ServerWorks: Unknown device 0227
00:10.0 Host bridge: ServerWorks: Unknown device 0101 (rev 05)
00:10.2 Host bridge: ServerWorks: Unknown device 0101 (rev 05)
01:01.0 Ethernet controller: Intel Corporation 8254NXX Gigabit Ethernet Controller (rev 04)
01:02.0 Ethernet controller: Intel Corporation 8254NXX Gigabit Ethernet Controller (rev 04)
02:01.0 Ethernet controller: Intel Corporation 8254NXX Gigabit Ethernet Controller (rev 03)
02:01.1 Ethernet controller: Intel Corporation 8254NXX Gigabit Ethernet Controller (rev 03)
02:03.0 Fiber Channel: QLogic Corp QLA231x/2340 (rev 02)
02:03.1 Fiber Channel: QLogic Corp QLA231x/2340 (rev 02)
|
リスト2には、マシン内のすべてのPCIコントローラーの概要が示されています。左の列は、カードのバス、スロット、およびファンクションを示しています。たとえば、指定02：01.0のイーサネット・コントローラーは、このカードがバス#02、スロット#01、ファンクション#0にあることを示しています。同じバス番号と同じスロット番号を持つ別のイーサネット・コントローラーがあるので（ファンクションは異なります）、これは2ポート・コントローラーです。
マシンにどんなものがあるかが分かったところで、これらのリソースのどれがコンソールに割り当てられ、どれが仮想マシンに割り当てられているかを調べる必要があります。このためには、tmp/vmkchdev.*.txt ファイルを見るか、コマンド/usr/sbin/vmkchdev を使用します。このコマンドの出力をリスト3に示します。
リスト3. vmkchdev からの出力
# /usr/sbin/vmkchdev -L
000:00.0 1166:0014 0000:0000 console
PCI device 1166:0014 (ServerWorks)
000:00.1 1166:0014 0000:0000 console
PCI device 1166:0014 (ServerWorks)
000:00.2 1166:0014 0000:0000 console
PCI device 1166:0014 (ServerWorks)
000:01.0 1002:5159 8086:34b1 console
PCI device 1002:5159 (ATI Technologies Inc)
000:15.0 1166:0203 8086:34b1 console
PCI device 1166:0203 (ServerWorks)
000:15.1 1166:0213 8086:34b1 console
PCI device 1166:0213 (ServerWorks)
000:15.2 1166:0221 8086:34b1 console
PCI device 1166:0221 (ServerWorks)
000:15.3 1166:0227 8086:34b1 console
PCI device 1166:0227 (ServerWorks)
000:16.0 1166:0101 0000:0000 console
PCI device 1166:0101 (ServerWorks)
000:16.2 1166:0101 0000:0000 console
PCI device 1166:0101 (ServerWorks)
001:01.0 8086:1028 8086:34b1 vmkernel vmnic3
PCI device 8086:1028 (Intel Corporation)
001:02.0 8086:1028 8086:34b1 vmkernel vmnic0
PCI device 8086:1028 (Intel Corporation)
002:01.0 8086:107b 8086:34b1 vmkernel vmnic1
PCI device 8086:107b (Intel Corporation)
002:01.1 8086:107b 8086:34b1 vmkernel vmnic2
PCI device 8086:107b (Intel Corporation)
002:03.0 1077:2312 1014:027d vmkernel vmhba0
PCI device 1077:2312 (Q Logic)
002:03.1 1077:2312 1014:027d vmkernel vmhba1
PCI device 1077:2312 (Q Logic)
|
この出力から、どのデバイスが vmkernel に割り当てられ、どれがコンソールによって所有されているかが分かります。consoleとなっている項目は、コンソールOSに割り当てられています。その他の項目はすべて、仮想マシンに割り当てられています。
左の列で、デバイスをlspci出力と照合することができます。etc/vmware/hwconfig ファイルにも同じ情報があります。hwconfigファイルでは、コンソールと仮想マシンの間で共有されているデバイスも分かります。
マシンにどのようなカードがあり、どのように割り当てられているかが分かったら、次は、正しいドライバーがロードされているかどうかを確認する必要があります。tmp/modules.*.txtファイルを見ると、コンソールOSが使用しているドライバーが分かります（リスト4を参照）。/sbin/lsmodコマンドで、同じ出力を得ることができます。
リスト4. lsmodからの出力
# /sbin/lsmod
Module Size Used by Tainted: PF
vmxnet_console 13212 1
vmnixmod 177056 3 [vmxnet_console]
e1000 68456 0 (unused)
usb-storage 20028 0
mousedev 3936 0 (unused)
keybdev 1696 0 (unused)
hid 17728 0 (unused)
input 3488 0 [mousedev keybdev hid]
usb-ohci 17600 0 (unused)
usbcore 50112 1 [usb-storage hid usb-ohci]
|
/etc/modules.confファイルでは、コンソールOSにロードされているモジュールのパラメーター設定を確認できます。
仮想マシンに対して正しいモジュールがロードされているかどうかも確認する必要があります。この情報は、tmp/vmkmod.*.txt ファイルにあります（リスト5を参照）。この情報は、/usr/sbin/vmkload コマンドで得ることもできます。
リスト5. vmkload_mod からの出力
# /usr/sbin/vmkload_mod -l
Name R/O Addr Length R/W Addr Length ID Loaded
vmklinux 0x4de000 0xf000 0x12438f8 0x53000 1 Yes
nfshaper 0x4ed000 0x1000 0x129b160 0x1000 2 Yes
e1000 0x4ee000 0xf000 0x129c168 0x6000 3 Yes
qla2300_604 0x4fd000 0x19000 0x12fe008 0x22000 4 Yes
bond 0x516000 0x2000 0x1574b80 0x2000 5 Yes
|
仮想マシンのモジュールにどのようなオプションが渡されているかを調べるには、ファイル tmp/vmkpcidivy.vmkmod.*.txt を見る必要があります（リスト6を参照）。
リスト6. vmkpcidivy.vmkmod.*.txt ファイルの内容
vmklinux linux
nfshaper.o nfshaper
e1000.o nic
qla2300_604.o fc qlloop_down_time=90 qlport_down_retry=10
|
接続されているストレージのタイプに基づいて、ファイバー・ストレージ用のさまざまなパラメーターが必要となることがあります。ストレージ・ベンダーが推奨する正しい設定になっていることを確認する必要があります。
特定のモジュールで使用可能なオプションを調べるには、やはり/usr/sbin/vmkload_mod コマンドを使用します（リスト7を参照）。
リスト7. vmkload_mod からの出力
# vmkload_mod -s mptscsi
Using /usr/lib/vmware/vmkmod/mptscsi.o
mptscsih string
PortIo int, description "[0]=Use mmap, 1=Use port io"
|
システム・ストレージ問題の多くは、設定の誤りか、ESXサーバー以外の問題が原因です。FAStTの設定誤りのほとんどは、「IBM RedbookImplementing VMware ESX Server 2.1 with IBM TotalStorage FAStT」を読むことで解決できます（リンクは、参考文献を参照）。
ストレージ問題のもうひとつの原因は、互換性問題です。これらの問題は、「System, I/O, SAN, and Backup Compatabilty Guides」（リンクは、参考文献を参照）に従って解決してください。
正しくセットアップされた構成は、図1のようになるはずです。
図1. VMware ESX マルチパス構成
ほとんどの場合、各LUN（Logical Unit Number：論理ユニット番号）へのパスが4つあります（LUNは、ストレージ・デバイスの物理特性を認識する必要があるアプリケーションを仮想マシンで実行している場合に役立ちます）。ただし、ローカルLUNとフェイルオーバーが重要でないものは除きます。典型的なレイアウトは、tmp/vmkmultipath.*.txtファイルか、vmkmultipath コマンドを発行することで確認できます（リスト8を参照）。
リスト8. vmkmultipath からの出力
# /usr/sbin/vmkmultipath -q
Disk and multipath information follows:
Disk vmhba0:0:0 (225,278 MB) has 4 paths. Policy is mru.
vmhba0:0:0 on (active, preferred)
vmhba0:1:0 on
vmhba1:0:0 on
vmhba1:1:0 on
|
アクティブ・パス（active）と優先パス（preferred）が同じでない場合は、配線、ゾーニング、またはハードウェア問題の可能性があります。この種の障害があるときに var/log/vmkernel に表示される一般的なメッセージをリスト9に示します。
リスト9. var/log/messagesの例
Jan 6 10:21:36 vmware01-ss vmkernel: 0:00:00:57.966 cpu1:132) WARNING: SCSI: 2046: Manual
switchover to path vmhba3:0:5 begins.
Jan 6 10:21:36 vmware01-ss vmkernel: 0:00:00:57.966 cpu1:132) SCSI: 2050: Changing active
path to vmhba3:0:5
Jan 6 10:21:36 vmware01-ss vmkernel: 0:00:00:57.967 cpu1:132) WARNING: SCSI: 1683: Did not
switchover to vmhba3:0:5. Check Unit Ready Command returned READY instead of NOT READY for
standby controller .
Jan 6 10:21:36 vmware01-ss vmkernel: 0:00:00:57.967 cpu1:132) WARNING: SCSI: 2089: Manual
switchover to vmhba3:0:5 completed successfully.
|
どのネットワーク・デバイスが仮想マシンに割り当てられているかが理解できたら、次に、それらがどのように使用されているかを理解しなければなりません。この情報を得るには、etc/vmware/hwconfig と etc/vmware/netmap.conf を見る必要があります。netmap.confファイルを見ると、内部ESXスイッチの名前と、それらが使用しているデバイスが分かります（リスト10を参照）。
リスト10. netmap.confのテキストの例
# cat netmap.conf
network0.name = "External Linux Net"
network0.device = "vmnic0"
network1.name = "Internal Windows Net"
network1.device = "vmnet_0"
network2.name = "Public Web access"
network2.device = "bond0"
|
この例では、サーバー上に2つの仮想スイッチがあることと、それらの名前（.name）、それらが使用しているデバイス（.device）が分かります。デバイスが実デバイスでない場合（vmnicまたはbond）、仮想スイッチにアウトバウンド・アダプターは割り当てられません。
アウトバウンド・アダプターがbondの場合、etc/vmware/hwconfig ファイルには、他にも貴重な情報が含まれています（リスト11を参照）。
リスト11. hwconfigファイルのテキストの例
nicteam.vmnic0.team = "bond0"
nicteam.vmnic1.team = "bond0"
|
この2つのnicは1つのNICとして結合されています。
ネットワークに関する診断情報は、いくつかの場所から得ることができます。まず最初は、proc/vmware/net です。ここには、システム上のNICとbondごとのサブディレクトリーがあります。proc/vmware/net/vmnic0/config からの例をリスト12に示します。
リスト12. configファイルのテキストの例
VLanHwTxAccel Yes
VLanHwRxAccel Yes
VLanSwTagging Yes
PromiscuousAllowed No
InterruptClustering No
Link state: Up
Speed: 1000 Mbps, full duplex
Queue: Running
PCI (bus:slot.func): 1:0.0
Minimum Capabilities 0x0
Device Capabilities 0x74b
Maximum Capabilities 0x76b
NICTeamingMaster: bond0
TeamFailoverBeacon: Off
Interrupt vector 0x69
DebugSocket Closed
|
これを見ると、リンクがアップ状態であり、使用可能であることが分かります。ダウン状態は、ケーブルまたはネットワーク・スイッチ・ポートに問題がある可能性を示します。このディレクトリーには、各種のネットワーク統計の一覧を示すstatsファイルもあります。
もうひとつの情報源は、var/log/vmkernel と var/log/messages です。次のようなメッセージ（リスト13を参照）が大量に記録されている場合は、NICとスイッチの間での速度と全二重/半二重のネゴシエーションに問題がある可能があります。
リスト13. messagesファイルのサンプルの例
Feb 2 12:48:23 SYNVM7 kernel: bcm5700: eth0 NIC Link is DOWN
Feb 2 12:48:23 SYNVM7 kernel: bcm5700: eth0 NIC Link is UP, 1000 Mbps full duplex
|
場合によっては（Broadcom NICとCiscoスイッチでは特に）、速度と全二重/半二重をカードとスイッチにハードコード化しなければならないかもしれません。この問題はESX V2.5で解決される予定ですが、このリリースではauto-negotiateに設定してください。ハードコード化するには、仮想マシンについてはMUIを使用し、コンソールOSイーサネットについては/etc/modules.confで行ってください。
ネットワーク問題を確認するためのもうひとつの情報源は、proc/net/nicinfoです。このディレクトリー内のファイルには、ネットワーク問題の障害カウントが含まれています。Rx_Packets、Tx_Packets、Rx_Bytes、Tx_Bytes以外の統計でゼロになっていない行がある場合は、外部ネットワークかNICそのものに問題があります。
ディスク問題が1つの仮想マシンに限定されているように思われる場合は、最初にその仮想マシンのログ・ファイルを見てください。これらは、.vmxファイルと同じ場所（etc/vmware/vm-list）にあります。
そのような種類の障害があった場合には、.vmxファイルに次のように記録されています。
リスト14. vmware.logファイルのテキストの例
Feb 02 11:39:07: vmx| DiskVmnixSetupSCSIDevices: failed to get handle for SCSI Device 0
Feb 02 11:39:07: vmx| Msg_Post: Error
Feb 02 11:39:07: vmx| [msg.diskVmnix.scsiopenfailed] Unable to open scsi target
VMFS-SAN1:mywindowsmachine.vmdk: Device or resource busy(2)
Feb 02 11:39:07: vmx| [msg.vmxlsilogic.poweronFailed]
Feb 02 11:39:07: vmx| Failed to configure scsi0.
Feb 02 11:39:07: vmx| ----------------------------------------
Feb 02 11:39:07: vmx| POST(no connection): Unable to open scsi target VMFS-SAN1:
mywindowsmachine.vmdk: Device or resource busy(2)
Feb 02 11:39:07: vmx|
Feb 02 11:39:07: vmx| Failed to configure scsi0.
Feb 02 11:39:07: vmx|
Feb 02 11:39:07: vmx| Module VmxLSILogic power on failed.
|
これは、ストレージ・デバイスに問題があるか、他の仮想マシンがディスク・ファイルを使用していることを示しています。プロセス・テーブル・リストを見ると、どれがどのファイルを使用しているかが分かります。たとえば、"ps -efwww"の出力（またはtmp/ps.*.txtファイル）が次のように表示されたとします。
リスト15. psコマンドの出力例
root 2751 0.0 1.7 404252 6612 ? S< 12:29 0:00 vmware-mks -A 11 -D 13
-S -L /tmp/vmware-root-2750.log -P 2750 -g -@ vm=374709cf368cf239; gui=false;
vmdbMemMapHandle=0x4; vmdbMemMapSize=0x400000;
useSELinux=false -C /home/vmware/mywindowsmachine/mywindowsmachine.vmx
|
プロセスがハングしていて、そのプロセスがファイルをつかまえている場合、仮想マシンはそのファイルのロックを取得できません。ストレージが共有されている場合は、仮想マシンが別のESXサーバー上で実行していないことを確認する必要があります。
通常、仮想マシンのネットワーク問題は、システムの設定誤りか、速度または全二重/半二重問題に関係しています。たとえば、仮想マシンがあるbond内のNICの1つにネットワーク問題があるのかもしれません。
ときには、仮想マシン内のドライバーに問題があることもあります。VMwareツールを再インストールすれば、この問題は解決します。これをテストするには、MUIでvlanceドライバーをvmxnetドライバーに、またはその逆に切り替えてみてください。
NICをシステムから取り外したり取り付けたりした場合に問題が発生することもあります。NICの着脱によってデバイスのずれが生じることがあります（たとえば、vmnic1がvmnic0になった場合など）。この場合は、VMの構成を編集して、正しいvmnicまたはbondを指し、正しいネットワーク上にあるようにしなければなりません。この問題のもうひとつのトラブルシューティング方法は、NICをコンソールOSに変更して、インターフェイスを起動し、そのネットワーク上の他のIPにpingが通じることを確認する方法です。
システムが突然シャットダウンしたりパニック状態になったりした場合、MUIにはシステム障害の際にロックされていたファイルをクリーンアップする時間がないため、起動時からMUIに問題が起きることがあります。
その他のMUI障害としては、MUIが動作不能になったり、コマンド・ラインとの同期が取れなくなったりするなどの問題があります。最も手っ取り早い解決方法は、MUIの再起動を試してみることです。これが仮想マシンに何らかの影響を与えることはありません。このためには、次のserviceコマンドを発行します（リスト16を参照）。
リスト16. serviceコマンドの出力例
# service httpd.vmware restart
Shutting down http.vmware: [ OK ]
Starting httpd.vmware: [ OK ]
|
MUIの間欠的な問題は、コンソールOSの速度と全二重/半二重問題に関係していることがあります。/etc/modules.confの設定を確認してください。
最後の手段として、MUIを再インストールすることもできます。rpmはインストールCDにあり、一般にVMware-mui-2.1.2-9638.rpmという形式の名前です（バージョンはシステム上のVMwareのバージョンに一致します。実行しているESXのリリースによって、9638以外のバージョンのこともあります）。rpm -e VMware-mui-2.1.2-9638でMUIを削除して、rpm -i VMware-mui-2.1.2-9638.rpm で新しいMUIをインストールできます。
この記事で述べたテクニックと例は、VMwareシステム、すなわち、システムのストレージとネットワーク、仮想マシンのストレージとネットワーク、およびMUIの問題特定と解決の出発点になるはずです。
-
VMware Knowledge Base article #653で、最新のvmサポート・スクリプトを入手してください。
-
VMware Knowledge Base article #1365で、診断情報収集に関する情報を入手してください。
- FAStT情報でVMwareを設定するために、Implementing VMware ESX Server 2.1 with IBM TotalStorage FAStT（IBM Redbooks, 2004年9月）を見てください。これは、VMware ESXサーバー・ホスト環境でFAStTストレージ・ソリューションを計画、設計、実装、維持管理するための推奨事項をまとめたものです。
- 互換性情報を調べる必要がある場合には、System, I/O, SAN, and Backup Compatibility Guidesを見てください。
- インストールや管理に関する情報については、ESX Server 2.5 Installation and Administration Guideを見てください。
- 「Use VMware to test your grid application」（developerWorks, 2004年8月）は、グリッド・アプリケーションのテストにおいて、いかにVMwareが強力なツールであるかを示すチュートリアルです。
-
Server Consolidation with VMware ESX Server（IBM Redbook Redpaper, 2005年1月）は、サーバー統合における選択肢と、その一つとしてのVMware ESX Serverを議論しています。
-
developerWorksのLinuxゾーンでは、Linux開発者のための資料が豊富に用意されています。
- 皆さんの次期Linux開発プロジェクトを、IBM trial softwareを使って革新してください。developerWorksから直接ダウンロードすることができます。
Greg LindleyはIBMのVMware ESX製品サポートのチーム・リーダーとして、過去2年間の大部分はVMware製品のサポートを行ってきました。またLinuxのサポートに5年以上、UNIXサポートに15年以上の経験を積んでいます。連絡先はlindleyg@us.ibm.comです。
目次
タグ
スライダーバーを使用することで、より多く（少なく）タグを表示します。
人気のタグは、この特定のコンテンツ・ゾーン（例えば、Java テクノロジー、Linux や WebSphere など）に対するトップのタグを表示します。
マイ・タグは、この特定のコンテンツ・ゾーン（例えば、Java テクノロジー、Linux や WebSphere など）に対するお客様ご自身のタグを表示します。
記事の人気タグ |
記事のマイ・タグタグ・リストへスキップ
記事の人気タグ |
記事のマイ・タグ