诊断VMware系统问题

1、诊断 VMware系统问题VMware ESX服务器允许在一台服务器上以虚拟机的形式运行多个类似的或完全不同的操作系统实例，因此合并应用程式的工作负荷就简单而迅速。不过即使采用了最佳的、最综合的方案，系统还是可能崩溃。为了帮助进行故障排除，在VMwareESX 服务器崩溃时，你能以多种方法，根据崩溃的现象对问题进行分类。最常见的方法是分类归入到四维矩阵中，矩阵的一个轴上是服务器和 虚拟机，另外一个轴上是网络 和 存储。此外，更有一个经常出现问题的地方是管理用户界面（Management User Interface， MUI ），他不时地会遇见问题。当崩溃发生时，诊断的第一步是搜集诊断数据?

2、收集完诊断数据之后，你就能分析数据来找出崩溃的原因了。接下来的几节向你展示了怎么搜集数据，到哪里查找信息，及怎么解释信息。搜集诊断数据要搜集的第一部分关键数据是由/usr/bin/vm-support 脚本产生的输出文件。这个文件放在当前目录中，并被命名为esx-XXXX-XX-XX.XXXX.tgz （其中 X 是日期 /进程标识符信息，例如 esx-2005-01-04.27059.tgz ）。VMware 会定期更新 /usr/bin/vm-support 脚本。为了搜集最精确的信息，请下载并安装最新版本。此外，如果你正遇见VirtualCenter 的问题，那么还需要搜集 Virtua

3、lCenter 日志（对这个问题的诊断不在本文的范围内）。所有的最新版本请参阅参考资料。搜集完这些信息之后，你就能将vm-support 输出文件（为二进制模式）传输给适当的支持人员来诊断。要在一个基于Linux 的系统上提取这个文件，请执行下面的命令： tar zxvf esx-XXXX-XX-XX.XXXX.tgz。诊断系统概述让我们从系统的高度来看一下系统中的硬件是怎么设置和分配的。你能使用命令行工具来查看，或查看/usr/bin/vm-support 文件的输出。/usr/bin/vm-support的输出是个使用 gzip 压缩过的 tar 文件，展开以后包含以下目录：清单 1. v

4、m-support输出的布局etc/proc/root/tmp/usr/var/根据 .vmx设置文件的位置的不同，还可能包含home 或 vpx。要全方面了解ESX服务器的布局，能从tmp目录开始。系统PCI总线设备的信息在文件中。运行/sbin/lspci命令你可获得同样的输出。清单2 展示了一个输出清单的例子。清单 2. lspci的输出# /sbin/lspci00:00.0 Host bridge: ServerWorks: Unknown device 0014 (rev 33)00:00.1 Host bridge: ServerWorks: Unknown device 001

5、400:00.2 Host bridge: ServerWorks: Unknown device 001400:01.0 VGA compatible controller: ATI Technologies Inc Radeon VE QY00: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 0

6、221 (rev 05)00:0f.3 Host bridge: ServerWorks: Unknown device 022700: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 8254NXXGigabit Ethernet Controller (rev 04)01:02.0Ethernetcontro

7、ller:IntelCorporation8254NXXGigabitEthernetController (rev 04)02:01.0Ethernetcontroller:IntelCorporation8254NXXGigabitEthernetController (rev 03)02:01.1Ethernetcontroller:IntelCorporation8254NXXGigabitEthernetController (rev 03)02:03.0 Fiber Channel: QLogic Corp QLA231x/2340 (rev 02)02:03.1 Fiber Ch

8、annel: QLogic Corp QLA231x/2340 (rev 02)清单2 给出了机器中所有的PCI控制器的一个列表。左边的一列告诉你总线、插槽和插件的功能。例如，规范说明为02:01.0的以太网控制器，告诉你这个插件是在#02总线的#01插槽中，其功能是#0。因为更有另一个有着相同的总线和插槽编号（而功能不同）的以太网控制器，所以这是个两口的控制器。既然我们已知道机器中都有什么了，那么我们需要看一下这些资源中哪些分配给了控制台，哪些分配给了虚拟机。为此，能看一下文件，或使用/usr/sbin/vmkchdev命令，该命令的输出如清单3 所示。清单 3. vmkchdev的输出#

9、/usr/sbin/vmkchdev -L000:00.0 1166:0014 0000:0000 consolePCI device 1166:0014 (ServerWorks)000:00.1 1166:0014 0000:0000 consolePCI device 1166:0014 (ServerWorks)000:00.2 1166:0014 0000:0000 consolePCI device 1166:0014 (ServerWorks)000:01.0 1002:5159 8086:34b1 consolePCI device 1002:5159 (ATI Technol

10、ogies Inc)000:15.0 1166:0203 8086:34b1 consolePCI device 1166:0203 (ServerWorks)000:15.1 1166:0213 8086:34b1 consolePCI device 1166:0213 (ServerWorks)000:15.2 1166:0221 8086:34b1 consolePCI device 1166:0221 (ServerWorks)000:15.3 1166:0227 8086:34b1 consolePCI device 1166:0227 (ServerWorks)000:16.0 1

11、166:0101 0000:0000 consolePCI device 1166:0101 (ServerWorks)000:16.2 1166:0101 0000:0000 consolePCI device 1166:0101 (ServerWorks)001:01.0 8086:1028 8086:34b1 vmkernel vmnic3PCI device 8086:1028 (Intel Corporation)001:02.0 8086:1028 8086:34b1 vmkernel vmnic0PCI device 8086:1028 (Intel Corporation)00

12、2:01.0 8086:107b 8086:34b1 vmkernel vmnic1PCI device 8086:107b (Intel Corporation)002:01.1 8086:107b 8086:34b1 vmkernel vmnic2PCI device 8086:107b (Intel Corporation)002:03.0 1077:2312 1014:027d vmkernel vmhba0PCI device 1077:2312 (Q Logic)002:03.1 1077:2312 1014:027d vmkernel vmhba1PCI device 1077:

13、2312 (Q Logic)这个输出告诉你哪些设备被分配给vmkernel ，而哪些设备归控制台所有。写着console 的条目被分配给了控制台 OS ；其他所有的设备都被分配给了虚拟机。你能把左边一列的设备和lspci的输出相匹配。你也能在etc/vmware/hwconfig文件中找到一些同样的信息。hwconfig文件也会告诉你哪些设备是在控制台和虚拟机之间共享的。知道机器中有哪些插件及这些插件怎么分配之后，你需要确保加载了正确的驱动程式。在文件中，你能看到控制台OS正在使用哪些驱动程式（参见清单4 ）。使用/sbin/lsmod命令能获得同样的输出结果。清单 4. lsmod的输出#

14、/sbin/lsmodModuleSize Used by Tainted: PFvmxnet_console132121vmnixmod1770563 vmxnet_consolee1000684560 (unused)usb-storage200280mousedev39360 (unused)keybdev16960 (unused)hid177280 (unused)input34880 mousedev keybdev hidusb-ohci176000(unused)usbcore501121usb-storage hid usb-ohci在 /etc/modules.conf文件

15、中，能找到加载在控制台OS 中的模块的参数设置。还需要确保也为虚拟机加载了正确的模块。该信息保存在文件中（参见清单5 ）。用/usr/sbin/vmkload命令也能找到该信息。清单 5. vmkload_mod的输出# /usr/sbin/vmkload_mod -lNameR/O AddrLengthR/W AddrLengthID Loadedvmklinux0x4de0000xf0000x12438f80x530001Yesnfshaper0x4ed0000x10000x129b1600x10002Yese10000x4ee0000xf0000x129c1680x60003Yesqla

16、2300_604 0x4fd0000x19000 0x12fe0080x220004 Yesbond0x5160000x20000x1574b800x20005Yes要看到哪些选项被传递给虚拟机的模块，需要查看文件（参见清单6）。清单文件的内容vmklinux linuxnfshaper.o nfshapere1000.o nicqla2300_604.o fc qlloop_down_time=90 qlport_down_retry=10基于所连接的存储类型的不同，可能需要不同的光纤存储参数。你需要确保已设置了存储供给商所推荐的正确设置。要看到给定模块的可用选项，能再次使用 /usr/sb

17、in/vmkload_mod命令（参见清单7 ）。清单 7. vmklost_mod的输出结果# vmkload_mod -s mptscsiUsing /usr/lib/vmware/vmkmod/mptscsi.omptscsih stringPortIo int, description "0=Use mmap, 1=Use port io"系统存储故障排除系统存储的非常多问题都是由于错误设置或ESX服务器之外的问题所引起的。通过阅读IBM 的红皮书ImplementingVMwareESX Server2.1 with IBMTotalStorage FAStT （

18、参见参考资料中的链接），能解决大部分的FAStT 错误设置问题。引起存储问题的另外一个原因可能是兼容性问题。按照System, I/O, SAN, and Backup Compatabilty Guides（参见 参考资料中的链接）去做，能帮助你解决这些问题。正确设置之后，设置应该和图1 类似。图 1. VMware ESX多路设置在大部分情况下，你应该会看到，到每个LUN （逻辑单元号，如果你正在一台需要看到存储设备物理特性的虚拟机上运行应用程式，他就有用了）都有4 条路 径， 本地LUN和那 些 故 障 恢复 不 紧 急 的情 况除 外。 在文 件 中 ， 你能 看到 一 个典 型 的

19、布 局， 这 也 能 通过 执 行vmkmultipath命令来看到（参见清单8 ）。清单 8. vmkmultipath的输出# /usr/sbin/vmkmultipath -qDisk and multipath information follows:Disk vmhba0:0:0 (225,278 MB) has 4 paths. Policy is mru.vmhba0:0:0on (active, preferred)vmhba0:1:0onvmhba1:0:0onvmhba1:1:0on如果活动路径和最佳选择路径不同，就非常可能存在布线、分区或硬件问题。这种崩溃在var/log

20、/vmkernel中产生的典型消息可能包括如清单9 所示的内容。清单 9. var/log/messages例子Jan 610:21:36 vmware01-ss vmkernel:0:00:00:57.966cpu1:132)WARNING:SCSI: 2046: Manualswitchover to path vmhba3:0:5 begins.Jan 6 10:21:36 vmware01-ss vmkernel: 0:00:00:57.966 cpu1:132) SCSI:2050: Changing activepath to vmhba3:0:5Jan 610:21:36 vmw

21、are01-ss vmkernel:0:00:00:57.967cpu1:132)WARNING:SCSI: 1683: Did notswitchoverto vmhba3:0:5. Check Unit Ready CommandreturnedREADYinsteadof NOT READY forstandby controller .Jan 610:21:36 vmware01-ss vmkernel:0:00:00:57.967cpu1:132) WARNING:SCSI: 2089: Manualswitchover to vmhba3:0:5 completed success

22、fully.系统网络故障排除明白哪些网络设备被分配给虚拟机之后，接下来你需要弄明白虚拟机怎么来使用这些设备。有关这方面的信息，你需要查看etc/vmware/hwconfig和etc/vmware/netmap.conf。 netmap.conf文件告诉你内部ESX交换机的名字，及他们正在使用哪些设备（参见清单10 ）。清单 10. netmap.conf的示例文本# cat = "External Linux Net"network0.device = "vmnic0" = &

23、quot;Internal视窗系统 Net"network1.device = "vmnet_0" = "Public Web access"network2.device = "bond0"这个例子告诉你这个服务器上有两个虚拟交换机，他们的名字（ .name），及他们正在使用哪些设备（ .device ）。如果这个设备不是个真实设备（ vmnic 或 bond），那么就没有外部适配器分配给这个虚拟交换机。如果外部适配器是bond ，那么etc/vmware/hwconfig文件还会包含其他一些有价

24、值的信息（参见清单11 ）。清单 11. hwconfig文件的示例文本这两个网卡被绑定为一个NIC 。你能 在 几个 地 方找 到有 关 网 络 的诊断 信 息 。 第 一个 位置 是proc/vmware/net。你 会看 到系 统 中 的 每个NIC和bond都 有 一 个 子目 录。proc/vmware/net/vmnic0/config的一个例子如清单12 所示。清单 12. config文件的示例文本VLanHwTxAccelYesVLanHwRxAccelYesVLanSwTaggingYesPromiscuousAllowedNoInterruptClusteringNoLi

25、nk state:UpSpeed:1000 Mbps, full duplexQueue:RunningPCI (bus:slot.func):1:0.0Minimum Capabilities0x0Device Capabilities0x74bMaximum Capabilities0x76bNICTeamingMaster:bond0TeamFailoverBeacon:OffInterrupt vector0x69DebugSocketClosed这告诉你网络连接正常，可用。如果Link state为 down ，那么就显示网线或网络交换机端口可能有问题。在同一个目录下，你能看到有一个

26、stats文件，其中列出了各种网络统计信息。另外一个信息源是var/log/vmkernel和 var/log/messages 。如果你看到非常多下面类型的消息（参见清单13 ），那么NIC 就可能在和交换机协商速率/双工模式时出现了问题。清单 13. messages文件的示例文本Feb 2 12:48:23 SYNVM7 kernel: bcm5700: eth0 NIC Link is DOWNFeb 2 12:48:23 SYNVM7 kernel: bcm5700: eth0 NIC Link is UP, 1000 Mbps full duplex在某些情况下（尤其是Broadc

27、om NIC和 Cisco 交换机），你只能在网卡和交换机上都硬编码速率/双工模式。这个问题在ESX V2.5中已解决了，在这个版本中，客户应该将其设置为auto-negotiate。硬编码对于虚拟机是使用MUI，对于控制台OS 的以太网是在/etc/modules.conf中。确认网络问题的另外一个来源是proc/net/nicinfo 。这个目录中的文件包含了因网络问题而崩溃的次数统计。如果除了Rx_Packets 、Tx_Packets 、Rx_Bytes 或Tx_Bytes 之外，更有其他统计信息，就说明问题在于外部网络或可能是NIC 本身。虚拟机存储故障排除如果存在似乎只局限于一台虚

28、拟机的磁盘问题，那么要查看的第一个位置是这个虚拟机的日志文件。这些文件和.vmx文件在同一个位置： etc/vmare/vm-list 。在 .vmx文件中查看这种类型的崩溃信息，你可能会看到下面的信息；清单 14. vmware.log文件的示例文本Feb 02 11:39:07:vmx| DiskVmnixSetupSCSIDevices:failedto get handle forSCSI Device 0Feb 02 11:39:07: vmx| Msg_Post: ErrorUnable to open scsitargetVMFS-SAN1:mywindowsmachine.vm

29、dk: Device or resource busy(2)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 targetVMFS-SAN1:mywindowsmachine.vmdk: Device or resource busy(2)Feb 02 11:39:07: vmx|Feb 02 11:39:07: vmx| Failed to configure scsi0.Fe

30、b 02 11:39:07: vmx|Feb 02 11:39:07: vmx| Module VmxLSILogic power on failed.这能说明存储设备出现了问题，或其他虚拟机正在使用磁盘文件。你能查看一下进程表清单，从而判断谁正在使用给定的文件。例如，使用“ps- efwww”命令，你可能会看到下面的信息（这也能在文件中看到）：清单 15. ps命令的输出例子root2751 0.0 1.7 404252 6612 ?S<12:290:00vmware-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如果跟文件有关的一个进程挂起了，那么这就会使虚拟机不能对该