在本文的上半部分中，我们介绍了ESXi 4.1版本的新特性，如支持TSM等。下面我们来看看其他重要特性。

　　集成微软AD服务器支持

　　新版的ESXi将集成对微软活动目录服务（Active Directory Service）的支持。这对于VMware而言是很值得玩味的一点让步。很多年来客户都在不停地申请使用这项功能，但是他们的声音却似乎始终无法到达VMware。

　　过去，VMware在ESX主机平台上，对于提供第三方目录服务支持方面的认证，一直采取非常保守的策略。 在过去，很多用户都被迫转向使用笨重的esxcfg-auth, Steve Beaver的LDAP_SEARCH,或the Samba Project的 WinBind等产品，甚至是商业化软件来实现传统ESX主机跟VMware的核心认证系统兼容。而现在在TSM模式支持下，用户可以随心所欲地选择所需软件。

　　VMware认为在ESX主机和微软ADS之间进行分离会导致安全问题发生。但是如果目录服务失效的时候会发生什么情况？如果用户失去目录服务，至少他们会担心影响到ESX主机的登录。因此，看到VMware在这一点上作出让步让人感到非常地欣慰，而且我想如果VMware能够经常听一听用户的想法，他们将会获得更多的有价值的东西。

　　因此，现在我们可以把ESX主机连接到AD服务器，然后可以通过Windows客户端或者是在ESX主机Configuration 页内"Authentication Services"类型的服务器登录。AD服务器的支持不再仅限于ESXi主机，即使您是传统的ESX用户也可以享受到这种便利。

　　假设在AD域环境中，您创建了一个称为“ESX admins”的全局组。任何该组中的成员都可以获得在vSphere客户端及其相关管理工具的完全控制权，尽管这种控制权限在一定程度上会受到安全策略的限制。这种新的权限分配方法也包含了对ESX管理员能否登录DCUI以及本地/远程TSM方式的控制权限的管理。

　　我想这项新功能对于吸引用户切换到ESXi而言是非常重要的。VMware最终还是承认了微软AD服务在企业领域内的统治地位，而且VMware正在显示出对企业级安全问题越来越成熟的掌控能力。而这一点对于大多数的“本地用户组”技术来说，是无法应用于外部大系统的监控和管理的。

　　新的vCLI命令

　　对于传统的ESX平台最常听到的抱怨之一，就是针对VMware称为vCLI的 远程命令终端程序中，无法支持很多关键命令。尽管事实上VMware的PowerShell增强版，称为PowerCLI，对传统ESX的交互式命令而且还有vCLI批判地体无完肤。但是VMware无法支持部分命令的抱怨始终无法消除。

　　尽管如此，VMware还是继续对vCLI进行投入以使得用户在VMware环境工作下获得的体验，尽可能地无缝接近直接在物理终端上运行的效果。事实上，这种差距已经非常地微小。而让人感到疑惑的是，似乎VMware对于全面支持TSM的使用始终有所保留。

　　新版vCLI中增加了“esxcli”命令，这是一个通常用于配置高端存储设备参数时所使用的。例如，通过esxcli命令可以监管和改变到存储阵列的路径选择策略（经常使用的包括Fixed, Round-Robin, EMC PowerPath）。esxcli的改进工作主要在于对iSCSI堆栈的支持以及引入了esxcli swiscsi子命令用于：

• Session.Session主要用来管理iSCSI会话。
• NIC.NIC命令可以管理iSCSI占用的物理网卡（NCI）。
• Vmknic.Vmknic命令列出了可以用于绑定到iSCSI适配器的vmks(vmkernel virtual adapters).
• Vmnic.Vmnic列出所有可用的物理网络配置器。

　　客观地讲，这些新的命令选项对于传统ESX用户或是ESXi用户而言，都会很感兴趣，但是最主要的用途还在于它的出现缩短了两种不同平台之间的差距。公平地讲，最近VMware发布的产品对于iSCSI的支持已经极大地落后于其它的几种存储协议。直到vSphere 4.1为止，仍然没有PowerCLI cmdlets可以用于iSCSI管理，而且VMware大肆宣传的“host profile”功能也已经提供了对FC协议和NFS协议的支持，但是唯独缺少了iSCSI。我希望在vSphere 4.1发布后，这些差距可以被悄悄地弥补上。

　　另外，新版esxcli命令中，引入了对于下一代vStorage APIs for Array Integration (VAAI 一个嵌入式插件)中所列出设备的支持。VAAI将会变得非常地庞大，而且将会提供对很多主流厂商的支持，如EMC和NetApp可以深入到ESX虚拟化管理程序中以提供更加智能的功能增强。例如“copy-offload”功能将会极大地降低在完成存储相关任务时所需的时间，如新虚拟机的克隆或者是执行Storage VMotion功能等等。最后一点，esxcli引入了“esxcli vms”类似的子命令，允许管理员可以强制停止某个无法对其它命令或API做出响应的虚拟机，功能类似于“kill”命令。

　　或许您已经看到，ESXi中进行了很多的增强和改进。其中一些甚至在VMware犹豫不决的领域做出了一定程度的让步。我认为这样的转变，在VMware的意愿中是希望通过支持一些特定的功能来缓解用户对于ESX平台即将退出市场这种行为的敌意。这些将帮助VMware建立一些成功案例，以消除对其它平台兼容的技术壁垒。

　　如果您的中期或长期计划中依然要采用VMware平台的话，那么一定要时刻记住这样的切换已经被提出很多年了。个人而言，我从ESX 3.5时代就开始同时使用ESX和ESXi平台。因为我希望可以更多地了解ESXi的不足，而且劝说自己放弃使用ESX service console。我想现在是一个很好的机会来重新编写我之前的文章：“build process for ESX to include PowerShell scripts”。因此，我认为这样改变进行地越早越快，在新平台的使用上就会越加地顺利。

　　ESXi的第一次出现可以追溯到2007年在戛纳举行的VMworld Europe大会上。当时VMware Community激烈地讨论着这样的架构是否已经可以适应生产环境的应用，但是这样的讨论更多地仅仅停留在理论阶段。实际上，使用VMware平台是要付出相应的代价的。如果您还希望继续使用VMware产品，那么当vSphere 5开始应用于业务环境中时，您就必须去适应ESXi产品。如果这样，还不如从现在开始就这么做。