在某些情况下，每一个系统管理员需要知道VI3（VMware Infrastructure 3）工作平台以某种特定方式运行的原因，或者某个特定事件发生的原因。如果标准接口工具不能够提供足够的信息，这个时候就需要考虑使用更好的方法了。幸运的是现在有一些方法可以用来收集更多的信息，但问题是这些信息分散在不同的地方。在本文中我们将探讨VI3的诊断数据（diagnostic data）功能，并且描述它对VI3执行管理员有何帮助。

　　从VI Client（VMware Infrastructure Client）中导出诊断数据

　　VI Client中的导出诊断数据任务能准确完整地收集信息，这些信息主要涉及到VirtualCenter、VI Client和ESX主机。如果用户和VMware技术支持人员交流过的话，他们就知道技术支持人员要他们做的第一步工作就包括导出诊断数据。这项任务可以在VI Client中生成诊断卷的滚动日志中可以看到。这个多维卷为一组选定资源的诊断问题提供了一个很好的开端，稍后，我们将会通过vm-support命令来解释诊断过程的主机部分，但是诊断数据卷的VirtualCenter和VI Client组件却和VI Client内的管理任务相关。

　　从管理菜单中可以很容易生成诊断数据，选择“Export Diagnostic Data”，用户就可以看到类似于如下的界面：

 
　　在一台单独的主机上完成这项任务需要花费一定的时间，如果同时选定多个主机的话，就会需要相当长的时间来复制文件，因为每台主机要复制的文件都超过15MB。VirtualCenter导出的文件可能会更大；从文件的大小来看，VI Client导出的文件一般要比一台主机导出的文件要小。在导出诊断数据程序运行过程中，VI Client上将会显示如下的滚动日志记录：

 
　　VirtualCenter数据的导出

　　VirtualCenter导出的文件，作为导出诊断数据过程的一部分，包含在一个vcSuppout压缩文件内。这些搜集到的数据包括Windows事件日志、VirtualCenter主机配置数据、vpxd-x.log日志文件、关键VMware服务信息以及来自VirtualCenter服务器的其它配置项目。

　　导出诊断数据功能的关键区域之一是与VI Client相关的目录。这是一个非常重要的因素，因为随着VI插件化架构的成熟，安装的各种各样的插件可能影响到VI Client对VirtualCenter访问的正常操作。从官方的立场来看，是不支持非VMware公布的插件的，但是用户还是经常使用这些插件，并且相当多的插件对于日常管理工作来讲是相当方便的。

　　在对一个测试系统导出诊断数据的过程中，viclient-9.log文件有一条记录显示在某一设备上我正在使用一个插件，如下所示：
[viclient:QuickInf] 2008-10-29 19:21:59.808 
     Load plugin: net.sf.vip.svmotion.SVMotionPlugin
除了插件，VI Client导出的信息对操作平台提供了一个全面的补充，这个操作平台描述的是和VirtualCenter交互的细节信息。

　　直接在主机上运行vm-support

　　VI Client诊断数据任务包括基于主机的数据。使用vm-support命令，可以直接在一台主机上运行任务。导出的主文件夹中保留的文件和文件夹使用记录，和在VI Client或者在ESX主机上直接使用vm-supprot命令后保留的文件和文件夹使用记录相同。vm-support命令创建一个压缩文件以及一个特定主机类型的日志，VMware支持服务人员可以使用这个日志来诊断出现的问题。下图是vm-support任务运行在一台ESX服务器上情况：

 
　　关于ESX主机，vm-support和VI Client最初导出的诊断数据任务的实质性内容都存放在/var/log/vmware目录下的压缩文件里面。这是模仿ESX服务器上文件系统，因此如果用户在控制台上有导航文件或者有SSH会话的话，就会对此非常熟悉了。

　　存放在/var/log/vmware的压缩文件夹包含ESX工作平台的主要日志文件。虽然不可以访问动态的ESX日志文件，但是压缩文件夹内的数据可以保证登录信息在正在运行的ESX主机系统之外是可用的。另外，如果必要的话，压缩文件对VMware的技术支持人员可以是透明的。Hostd-x.log系列的文件包括大量的信息，所以全部浏览这些文件是一个比较麻烦的问题，在这些文件夹内搜索特定的条目有点不太可能。但是特定主机类型的ESX或者VirtualCenter的许多客体都是可以搜索得到的，下面是一些和被克隆及初始化的Client-5客体虚拟机相关的记录（对于这个特定的任务可能会更多）：
[2008-10-21 08:23:50.139
'vm:/vmfs/volumes/48e2ba85-22a32fd3-8f7d-00188b374d8b/
Client-5/Client-5.vmx' 3076449184 info] State Transition
(VM_STATE_INITIALIZING -> VM_STATE_ON)
 
[2008-10-21 08:23:50.161
'vm:/vmfs/volumes/48e2ba85-22a32fd3-8f7d-00188b374d8b/
Client-5/Client-5.vmx' 3076449184 info]
Initialized virtual machine.
 
[2008-10-21 08:23:50.173 'Vmsvc' 3076449184 info]
Loaded virtual machine:
/vmfs/volumes/48e2ba85-22a32fd3-8f7d-00188b374d8b/
Client-5/Client-5.vmx

　　可以搜索到的条目主要包括虚拟机的名字、完整的数据存储路径和时间框架。

　　为比较建立一个基准线

　　拥有访问日志文件的权限是不错，但如上所述，日志文件可能过于繁琐冗长。更进一步，我提到的还不及诊断数据导出文件中大量细节信息的冰山一角。在技术支持或者其他诊断性工作的过程中，拥有一个众所周知的对主机行为的正确输出信息是非常有帮助的，这个主机的行为主要来自vm-support或者VI Client任务。通过建立一个基准线或者正常配置，它可以帮助任何级别的技术支持和系统搜索。这个额外的信息有可能帮助区分什么是一个良性的错误，也有可能帮助标识需要注意的新的问题。

　　通过对每一台主机每月导出一次诊断数据来提供一个不错的基准线是一个不错的方法。这样以来，从存储设备、网卡驱动和动态工作负载的角度来看，vm-support或者VI Client导出诊断数据对主机配置的配置就比较有代表性了。通过规律性的数据导出，另外如果再有技术支持的参与，错误频率的历史记录可以被用来帮助诊断某个问题。

　　还有其他可以用的工具吗？

　　除了VI3提供的基本工具，很自然想到的其它工具就是VirtualCenter数据库。VPX_EVENT表中包括在VI3内通过VirtualCenter所有对象初始化的事件记录，其中包括试图登录系统的事件记录、VMware分布式资源调度程序（DRS：Distributed Resources Scheduler）事件、VMware高可用性（HA：High Availability）事件、主机配置活动、资源池管理和虚拟机配置。由于不允许访问运行时的VPX_EVENT表，所以查看表中记录的一个不错的方法就是把VPX_EVENT表存放在另外一个不同的数据库中，这样就可以在另外一个数据库中完成任何查询工作了。

　　也可以直接访问ESX主机、VirtualCenter服务器和VI Client上的日志文件。对于主机和VirtualCenter上的文件，需要格外注意动态日志文件，需要及时地备份到服务器和应用程序持续运行的路径之外的文件上，以免发生不一致性现象。在当前的系统版本中，许多ESX日志文件都保存在/var/log/vmware目录下；VirtualCenter日志文件在默认情况下都保存在C:Documents and SettingsAll UsersApplication DataVMwareVMware VirtualCenterLogs目录下；VI Client日志在默认情况下保存在C:Documents and SettingsusernameLocal SettingsApplicationDataVMwarevpx目录下。

　　结论

　　VirtualCenter、ESX和VI Client的诊断数据的信息量都非常大。诊断数据的导出对VMware来讲是一个非常有用的支持工具，另外如果对基准线的内涵和正确操作都有一个很好的理解的话，诊断数据可以帮助提供VI3工作平台上的一个很好的基准线。