当 VMware 发生故障时 如何诊断 VMware 系统问题（2）

look_w

系统存储故障排除系统存储的很多问题都是由于错误配置或 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 的输出

1 2 3 4 5 6 7

# /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 中产生的典型消息可能包括如清单 9 所示的内容。
清单 9. var/log/messages 例子

1 2 3 4 5 6 7 8 9

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 的示例文本

1 2 3 4 5 6 7

# 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 文件的示例文本

1 2	nicteam.vmnic0.team = "bond0" nicteam.vmnic1.team = "bond0"

这两个网卡被绑定为一个 NIC。
您可以在几个地方找到有关网络的诊断信息。第一个位置是 proc/vmware/net。您会看到系统中的每个 NIC 和 bond 都有一个子目录。proc/vmware/net/vmnic0/config 的一个例子如清单 12 所示。
清单 12. config 文件的示例文本

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

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

这告诉您网络连接正常，可用。如果 Link state 为 down，那么就显示网线或网络交换机端口可能有问题。在同一个目录下，您可以看到有一个 stats 文件，其中列出了各种网络统计信息。
另外一个信息源是 var/log/vmkernel 和 var/log/messages。如果您看到很多下面类型的消息（参见清单 13），那么 NIC 就可能在与交换机协商速率/双工模式时出现了问题。
清单 13. messages 文件的示例文本

1 2	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 文件的示例文本

1 2 3 4 5 6 7 8 9 10 11 12 13

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 命令的输出例子

1 2 3 4

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 出现了问题而导致网络问题。
有时，您可能会看到虚拟机中的驱动程序有问题。重新安装 VMware 工具会修复这个问题。您可以在 MUI 中从 vlance 切换到 vmxnet 驱动程序上来测试一下，反之亦可。
如果向系统中添加或删除了一个 NIC，那么就可能会出现另外一个问题。这可能导致设备滑动（例如 vmnic1 变成 vmnic0）。在这种情况下，您应该编辑 VM 的配置文件，从而确保它指向正确的 vmnic 或 bond，并且位于正确的网络上。排除这个问题的另外一种方法是将 NIC 修改为控制台 OS，启动这个网卡，并确保您可以 ping 到这个网络中的其他 IP。
MUI 故障排除如果发生系统突然关机或 panic，MUI 可能在启动时很难打开，因为系统崩溃时 MUI 没有适当的时间来清除剩余的锁文件。
其他的 MUI 崩溃可能包括 MUI 死机，或者在使用命令行进行同步时出现问题。最快的解决方法是试着重新启动一下 MUI。这对虚拟机没有任何影响。为此，请执行下面的 service 命令（参见清单 16）：
清单 16. service 命令的输出例子

1 2 3

# 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问题。