诊断VMware系统问题.doc

诊断VMware系统问题VMware ESX 服务器允许在一台服务器上以虚拟机的形式运行多个类似的或完全不同的操作系统实例，因此合并应用程式的工作负荷就简单而迅速。不过即使采用了最佳的、最综合的方案，系统还是可能崩溃。 为了帮助进行故障排除，在 VMware ESX 服务器崩溃时，你能以多种方法，根据崩溃的现象对问题进行分类。最常见的方法是分类归入到四维矩阵中，矩阵的一个轴上是 服务器 和 虚拟机，另外一个轴上是 网络 和 存储。 此外，更有一个经常出现问题的地方是管理用户界面（Management User Interface，MUI），他不时地会遇见问题。 当崩溃发生时，诊断的第一步是搜集诊断数据 ? 收集完诊断数据之后，你就能分析数据来找出崩溃的原因了。接下来的几节向你展示了怎么搜集数据，到哪里查找信息，及怎么解释信息。 搜集诊断数据要搜集的第一部分关键数据是由 /usr/bin/vm-support 脚本产生的输出文件。这个文件放在当前目录中，并被命名为 esx-XXXX-XX-XX.XXXX.tgz（其中 X 是日期/进程标识符信息，例如 esx-2005-01-04.27059.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/lspci00:00.0 Host bridge: ServerWorks: Unknown device 0014 (rev 33)00:00.1 Host bridge: ServerWorks: Unknown device 001400: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 0221 (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 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 -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 Technologies 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 1166: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)002: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:2312 (Q Logic) 这个输出告诉你哪些设备被分配给 vmkernel，而哪些设备归控制台所有。写着 console 的条目被分配给了控制台 OS；其他所有的设备都被分配给了虚拟机。 你能把左边一列的设备和 lspci 的输出相匹配。你也能在 etc/vmware/hwconfig 文件中找到一些同样的信息。hwconfig 文件也会告诉你哪些设备是在控制台和虚拟机之间共享的。 知道机器中有哪些插件及这些插件怎么分配之后，你需要确保加载了正确的驱动程式。在 tmp/modules.*.txt 文件中，你能看到控制台 OS 正在使用哪些驱动程式（参见清单 4）。使用 /sbin/lsmod 命令能获得同样的输出结果。 清单 4. lsmod 的输出# /sbin/lsmodModule Size Used by Tainted: PFvmxnet_console 13212 1vmnixmod 177056 3 vmxnet_consolee1000 68456 0 (unused)usb-storage 20028 0mousedev 3936 0 (unused)keybdev 1696 0 (unused)hid 17728 0 (unused)input 3488 0 mousedev keybdev hidusb-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 -lName R/O Addr Length R/W Addr Length ID Loadedvmklinux 0x4de000 0xf000 0x12438f8 0x53000 1 Yesnfshaper 0x4ed000 0x1000 0x129b160 0x1000 2 Yese1000 0x4ee000 0xf000 0x129c168 0x6000 3 Yesqla2300_604 0x4fd000 0x19000 0x12fe008 0x22000 4 Yesbond 0x516000 0x2000 0x1574b80 0x2000 5 Yes 要看到哪些选项被传递给虚拟机的模块，需要查看 tmp/vmkpcidivy.vmkmod.*.txt 文件（参见清单 6）。 清单 6. vmkpcidivy.vmkmod.*.txt 文件的内容vmklinux linuxnfshaper.o nfshapere1000.o nicqla2300_604.o fc qlloop_down_time=90 qlport_down_retry=10 基于所连接的存储类型的不同，可能需要不同的光纤存储参数。你需要确保已设置了存储供给商所推荐的正确设置。 要看到给定模块的可用选项，能再次使用 /usr/sbin/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 的红皮书 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 -qDisk 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 中产生的典型消息可能包括如清单 9 所示的内容。 清单 9. var/log/messages 例子Jan 6 10:21:36 vmware01-ss vmkernel: 0:00:00:57.966 cpu1: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 6 10:21:36 vmware01-ss vmkernel: 0:00:00:57.967 cpu1:132) WARNING: SCSI: 1683: Did notswitchover to vmhba3:0:5. Check Unit Ready Command returned READY instead of NOT READY forstandby controller .Jan 6 10:21:36 vmware01-ss vmkernel: 0:00:00:57.967 cpu1:132) WARNING: SCSI: 2089: Manualswitchover to vmhba3:0:5 completed successfully. 系统网络故障排除明白哪些网络设备被分配给虚拟机之后，接下来你需要弄明白虚拟机怎么来使用这些设备。有关这方面的信息，你需要查看 etc/vmware/hwconfig 和 etc/vmware/map.conf 文件告诉你内部 ESX 交换机的名字，及他们正在使用哪些设备（参见清单 10）。 清单 10. netmap.conf 的示例文本# cat = External Linux Netnetwork0.device = = Internal 视窗系统 Netnetwork1.device = vmnet_0 = Public Web accessnetwork2.device = bond0 这个例子告诉你这个服务器上有两个虚拟交换机，他们的名字（.name），及他们正在使用哪些设备（.device）。如果这个设备不是个真实设备（vmnic 或 bond），那么就没有外部适配器分配给这个虚拟交换机。 如果外部适配器是 bond，那么 etc/vmware/hwconfig 文件还会包含其他一些有价值的信息（参见清单 11）。 清单 11. hwconfig 文件的示例文本nicteam.vmnic0.team = bond0nicteam.vmnic1.team = bond0 这两个网卡被绑定为一个 NIC。 你能在几个地方找到有关网络的诊断信息。第一个位置是 proc/vmware/net。你会看到系统中的每个 NIC 和 bond 都有一个子目录。proc/vmware/net/vmnic0/config 的一个例子如清单 12 所示。 清单 12. config 文件的示例文本VLanHwTxAccel YesVLanHwRxAccel YesVLanSwTagging YesPromiscuousAllowed NoInterruptClustering NoLink state: UpSpeed: 1000 Mbps, full duplexQueue: RunningPCI (bus:slot.func): 1:0.0Minimum Capabilities 0x0Device Capabilities 0x74bMaximum Capabilities 0x76bNICTeamingMaster: bond0TeamFailoverBeacon: OffInterrupt vector 0x69DebugSocket 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 DOWNFeb 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:39:07: vmx| DiskVmnixSetupSCSIDevices: failed to get handle for SCSI Device 0Feb 02 11:39:07: vmx| Msg_Post: ErrorFeb 02 11:39:07: vmx| msg.diskVmnix.scsiopenfailed Unable to open scsi targetVMFS-SAN1:mywindowsmachine.vmdk: Device or resource busy(2)Feb 02 11:39:07: vmx| msg.vmxlsilogic.poweronFailedFeb 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 如果跟文件有关的一个