如何诊断 VMware系统问题

尽管采用了弹性最好的方案，系统也有崩溃的时候。本文就为您提供一些解决系统崩溃的指导准则，包括到哪里去查看问题，以及如何解释问题，并提供一些问题修正的解答，本文的一切都是围绕 VMware ESX 框架进行的。VMware ESX 服务器允许在一台服务器上以虚拟机的形式运行多个类似的或完全不同的操作系统实例，因此合并应用程序的工作负荷就简单而迅速。但是即使采用了最好的、最综合的方案，系统还是可能崩溃。 为了帮助进行故障排除，在 VMware ESX 服务器崩溃时，您可以以多种方法，根据崩溃的现象对问题进行分类。最常见的方法是分类归入到四维矩阵中，矩阵的一个轴上是 服务器 和虚拟机，另外一个轴上是 网络 和存储。 此外，还有一个经常出现问题的地方是管理用户界面（Management User Interface，MUI），它不时地会遇到问题。 当崩溃发生时，诊断的第一步是搜集诊断数据 ? 收集完诊断数据之后，您就可以分析数据来找出崩溃的原因了。接下来的几节向您展示了如何搜集数据，到哪里查找信息，以及如何解释信息。 搜集诊断数据要搜集的第一部分关键数据是由 /usr/bin/vm-support 脚本产生的输出文件。这个文件放在当前目录中，并被命名为 esx-XXXX-XX-XX.XXXX.tgz（其中 X 是日期/进程标识符信息，例如 esx-2005-01-04.2705Array.tgz）。 VMware 会定期更新 /usr/bin/vm-support 脚本。为了搜集最精确的信息，请下载并安装最新版本。此外，如果您正遇到 VirtualCenter 的问题，那么还需要搜集 VirtualCenter 日志（对这个问题的诊断不在本文的范围内）。所有的最新版本请参阅 参考资料。 搜集完这些信息之后，您就可以将 vm-support 输出文件（为二进制模式）传输给适当的支持人员来诊断。要在一个基于 Linux 的系统上提取这个文件，请执行下面的命令：tar zxvf esx-XXXX-XX-XX.XXXX.tgz。 诊断系统概述让我们从系统的高度来看一下系统中的硬件是如何配置和分配的。您可以使用命令行工具来查看，或者查看 /usr/bin/vm-support 文件的输出。 /usr/bin/vm-support 的输出是一个使用 gzip 压缩过的 tar 文件，展开以后包含以下目录： 清单1. vm-support 输出的布局 etc/ proc/ root/ tmp/ usr/ var/ 根据 .vmx 配置文件的位置的不同，还可能包含 ‘home’ 或‘vpx’。 要全面了解 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 。因为还有另一个有着相同的总线和插槽编号（而功能不同）的以太网控制器，所以这是一个两口的控制器。 既然我们已经知道机器中都有什么了，那么我们需要看一下这些资源中哪些分配给了控制台，哪些分配给了虚拟机。为此，可以看一下 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:515Array 8086:34b1 console PCI device 1002:515Array (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 3Array36 0 (unused) keybdev 16Array6 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 0x12Arrayb160 0x1000 2 Yes e1000 0x4ee000 0xf000 0x12Arrayc168 0x6000 3 Yes qla2300_604 0x4fd000 0x1Array000 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=Array0 qlport_down_retry=10 基于所连接的存储类型的不同，可能需要不同的光纤存储参数。您需要确保已经设置了存储供应商所推荐的正确设置。 要看到给定模块的可用选项，可以再次使用 /usr/sbin/vmkload_mod 命令（参见清单 7）。 清单7. vmklost_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 服务器之外的问题所引起的。通过阅读 IBM 的红皮书 Implementing VMware ESX Server 2.1 with IBM TotalStorage FAStT（参见 参考资料 中的链接），可以解决大部分的 FAStT 错误配置问题。 引起存储问题的另外一个原因可能是兼容性问题。按照 System, I/O, SAN, and Backup Compatabilty Guides（参见 参考资料 中的链接）去做，可以帮助您解决这些问题。 正确设置之后，配置应该与图 1 类似。 图1. VMware ESX 多路配置在大部分情况下，您应该会看到，到每个 LUN（逻辑单元号，如果您正在一台需要看到存储设备物理特性的虚拟机上运行应用程序，它就有用了）都有 4 条路径，本地 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 如果活动路径与首选路径不同，就很可能存在布线、分区或硬件问题。这种崩溃在 var/log/vmkernel 中产生的典型消息可能包括如清单 Array 所示的内容。 清单Array. var/log/messages 例子 Jan 6 10:21:36 vmware01-ss vmkernel: 0:00:00:57.Array66 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.Array66 cpu1:132) SCSI: 2050: Changing active path to vmhba3:0:5 Jan 6 10:21:36 vmware01-ss vmkernel: 0:00:00:57.Array67 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.Array67 cpu1:132) WARNING: SCSI: 208Array: 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" 这个例子告诉您这个服务器上有两个虚拟交换机，它们的名字（.name），以及它们正在使用哪些设备（.device）。如果这个设备不是一个真实设备（vmnic 或bond），那么就没有外部适配器分配给这个虚拟交换机。 如果外部适配器是 bond，那么 etc/vmware/hwconfig 文件还会包含其他一些有价值的信息（参见清单 11）。 清单11. hwconfig 文件的示例文本 nicteam.vmnic0.team = "bond0" nicteam.vmnic1.team = "bond0" 这两个网卡被绑定为一个 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 0x6Array DebugSocket Closed 这告诉您网络连接正常，可用。如果 Link state 为 down，那么就显示网线或网络交换机端口可能有问题。在同一个目录下，您可以看到有一个 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 本身。 虚拟机存储故障排除如果存在似乎只局限于一台虚拟机的磁盘问题，那么要查看的第一个位置是这个虚拟机的日志文件。这些文件和 .vmx 文件在同一个位置：etc/vmare/vm-list。 在.vmx 文件中查看这种类型的崩溃信息，您可能会看到下面的信息； 清单14. vmware.log 文件的示例文本 Feb 02 11:3Array:07: vmx| DiskVmnixSetupSCSIDevices: failed to get handle for SCSI Device 0 Feb 02 11:3Array:07: vmx| Msg_Post: Error Feb 02 11:3Array:07: vmx| [msg.diskVmnix.scsiopenfailed] Unable to open scsi target VMFS-SAN1:mywindowsmachine.vmdk: Device or resource busy(2) Feb 02 11:3Array:07: vmx| [msg.vmxlsilogic.poweronFailed] Feb 02 11:3Array:07: vmx| Failed to configure scsi0. Feb 02 11:3Array:07: vmx| ---------------------------------------- Feb 02 11:3Array:07: vmx| POST(no connection): Unable to open scsi target VMFS-SAN1: mywindowsmachine.vmdk: Device or resource busy(2) Feb 02 11:3Array:07: vmx| Feb 02 11:3Array:07: vmx| Failed to configure scsi0. Feb 02 11:3Array:07: vmx| Feb 02 11:3Array:07: vmx| Module VmxLSILogic power on failed. 这可以说明存储设备出现了问题，或者其他虚拟机正在使用磁盘文件。您可以查看一下进程表清单，从而判断谁正在使用给定的文件。例如，使用“ps -efwww”命令，您可能会看到下面的信息（这也可以在 tmp/ps.*.txt 文件中看到）： 清单15. ps 命令的输出例子 root 2751 0.0 1.7 404252 6612 ? S< 12:2Array 0:00 vmware-mks -A 11 -D 13 -S -L /tmp/vmware-root-2750.log -P 2750 -g -@ vm=37470Arraycf368cf23Array; gui=false; vmdbMemMapHandle=0x4; vmdbMemMapSize=0x400000; useSELinux=false -C /home/vmware/mywindowsmachine/mywindowsmachine.vmx 如果跟文件有关的一个进程挂起了，那么这就会使虚拟机不能对该文件加锁。如果这个存储介质是共享的，那么您就需要确保这个虚拟机没有在另外一个 ESX 服务器上运行。 虚拟机网络故障排除通常，虚拟机网络的问题都是与系统的错误配置有关，或者可能是速率/双工模式的问题。例如，有一台虚拟机使用了一个 bond 设备，可能其中的一个 NIC 出现了问题而导致网络问题。 有时，您可能会看到虚拟机中的驱动程序有问题。重新安装 VMware 工具会修复这个问题。您可以在 MUI 中从 vlance 切换到 vmxnet 驱动程序上来测试一下，反之亦可。 如果向系统中添加或删除了一个 NIC，那么就可能会出现另外一个问题。这可能导致设备滑动（例如 vmnic1 变成 vmnic0）。在这种情况下，您应该编辑 VM 的配置文件，从而确保它指向正确的 vmnic 或 bond，并且位于正确的网络上。排除这个问题的另外一种方法是将 NIC 修改为控制台 OS，启动这个网卡，并确保您可以 ping 到这个网络中的其他 IP。 MUI 故障排除如果发生系统突然关机或 panic，MUI 可能在启动时很难打开，因为系统崩溃时 MUI 没有适当的时间来清除剩余的锁文件。 其他的 MUI 崩溃可能包括 MUI 死机，或者在使用命令行进行同步时出现问题。最快的解决方法是试着重新启动一下 MUI。这对虚拟机没有任何影响。