在这篇文章中，我想着重讲解一下在我浏览PowerCLI论坛时，看到的一些很有用的技巧。下面我将向你介绍这些技巧，会谈到PowerCLI是什么，以及我发现的一些特点。我还将提供涉及到的技术的一些背景资料。

　　PowerShell以外的思路

　　首先介绍的一个帖子是，“在ESX中，需要借助PowerShell脚本来找到某个虚拟机（VM）的进程ID（PID）。”此贴的前提是，作者需要找到一些信息，但他唯一知道获取到这些信息的途径就是登陆到ESX操作系统控制台（COS）。这就是为什么当前需求与他需要进程ID不符的原因了，但这足以证明，有时你为了完成某些诊断任务而必须登录到控制台。

　　这个帖子的特点在于，它似乎暴露了vSphere应用程序编程接口（API）上的某些不足，并需要以PowerCLI为辅助。就如所有的APIs一样，功能都是创建了一个抽象层，可以对某一产品或某一产品套件进行尽可能灵活的一致性编程，而且可以引入新的功能来降低软件开发任务的难度。问题是，与ESX虚拟化层进行沟通工作的操作系统控制台（COS）实际上也是一个操作系统，而操作系统往往都相当复杂，并且在某些情况下，用户接口也非常分散。

　　回到PowerCLI和vSphere API上来。架构在VMware最底层架构之上的vSphere API层是非常有层次架构，并提供了最外层的功能。操作系统却有着不一样的架构！很不幸的是，vSphere API并不能构建一张完美的流程图以使你可以登录到操作系统控制台（COS）。然而，PowerCLI也是基于某些API之上，这意味着你不能在操作系统（OS）控制台之内使用PowerCLI来执行相关任务——至少不是直接。这正是发布到论坛上的解决方案的用武之地。

　　对我们和原始帖子的作者来说幸运的事情是，PowerCLI是建立在PowerShell内，并且PowerShell可以调用一个外部进程作为脚本的一部分。该解决方案是在LucD的回贴中提到的。在这种情况下，外部进程是plink.exe，它是一个非常流行的安全命令行shell（SSH）客户端—PuTTY中的一部分。该脚本实现使用plink登录到ESX主机管理控制台，然后执行远程控制命令“vm-support”。此实用工具是一种收集信息的方法，正如原帖中提到的。

　　你可能会说这种行为有点像一个黑客，因为你不是通过“被认准的接口”来访问数据，但有些时候，你不得不去找到一个方法。这个特别帖子的寓意是：不要害怕，要跳出思想的框框。虽然vSphere API是一个相当大的框框，但它的目的不是为了解决你可能遇到的每一个vSphere系统的问题。事实上，对于它准确的理解是，它确实不适合用于诊断。

　　当PowerCLI的内置命令不起作用

　　这第二个帖子标题是，“使用脚本来配置vSwitch上的安全参数。”虽然在这个帖子中的脚本非常高深，但是我认为这将是一个很好的例子，因为我认为它描述了一种常见的场景，当你没有使用PowerCLI 内置命令而使用到vSphere API的功能。其基本前提是内置命令（在以前的文章我也谈到过）与API的功能没有100%的对等。然而，通过使用Get-View内置命令，再加上其他一些技巧，你就可以完成很多的需要做的事情。

　　此贴的作者想要说的是关于设置vSwitch安全方面的设置。我打开安全选项卡中的一个选项页面，当你打开一台虚拟交换机的性能属性时就可以看到，如下图：

　　不幸的是，你不能通过内置命令设置这些属性，下图为Set-VirtualSwitch命令的帮助文档：

　　该内置命令缺乏安全设置参数。也有可能，VMware正在并将继续缩短内置命令和API之间的差距，但今天它确实是帮不了我们了。

　　为了弥补暂时的不足，你必须使用Get-View的内置命令。Get-View是非常有用的?——它就像释放出一种技能以让你闯过难关。我不打算详细介绍有关的内置命令，但你需要知道的是，目前PowerCLI 内置命令给虚拟化管理员开发了一个可以与PowerShell协调工作的可定制接口。当它起作用时，这对于管理员来说是好消息，但是当你的操作受到了内置命令的制约，那么你必需采用底层API对象。换句话说，你需要理解一个完全不同的接口——这与程序员为vSphere开发软件时看到的一样。

　　回到帖子，帖子中有段代码，如下所示（为便于阅读，已稍微编辑）：

　　第1行检索了主机列表并将它们分配给一个变量。 第2行遍历该变量中包含的每个主机服务器，并找到名为“vSwitch2”的交换机。第3行在这里你可以看到Get-View内置命令的使用以获取原始对象。

　　4-6行，你会得到一个以一定方式命名的vSphere API，这些将为更新虚拟交换机做好准备——“艰难的方式”。

　　在第7行会报错。为了达到编辑虚拟交换机的目的，作者给出了非常有效的假设，所以你将使用到一个新的对象（这些通常是vSphere API使用来描述一个正在创建或修改的对象）。

　　但问题是，就像LucD在回复中做出的非常有用的解释，该API有时是相当挑剔。希望看到这个规范的对象是，它其中的每一个参数字段都被明确定义并赋予了默认值。在这一点上，你可以找出这些默认值应该是什么，也可以简单地复制一个已有的，之后再修改成你的内容。更新后的代码如下所示：

　　我想强调这个论坛帖子的目的是想强调什么方式才是将PowerShell和vSphere API对象协调工作的最佳方式。当你修改一个现有对象的时候，复制该对象的属性，然后再修改对象的属性。这将为你节省不必再通过API文档找到对象的正确默认值，因为那可能是一件头痛的事情，尤其当你去尝试使用对象的新属性的时候。但是，要记住，当你花时间来从头创建新对象的时候，那么这种便捷的方式对你不会有任何帮助。