当评估完成后，您可以更好地判断哪些机器可以迁移，哪些不能迁移。幸运的是，客户有严格的“每台机器一个应用程序”规则，这是强制的，并消除了可能的应用程序冲突和迁移问题。随着有关其当前基础设施的详细信息的发布，可以确定必要的硬件已经在使用，并且可以通过少量硬件升级进行重用。每台机器都需要双端口网卡和光纤通道卡，并增加内存和本地磁盘空间。运行所需的虚拟机数量和启用VMotion的使用,所有的机器都在每个站点至少配对,每网站进一步推荐购买另一台机器(因为没有更多的主机重用)最早的便利,以便他们可以缓解在未来可能的机器故障。要执行第一次迁移，需要从制造商那里借用一些种子单元，并从它们自己的san中划分lun，允许使用种子单元从物理迁移到虚拟。然后，物理主机将被转换为ESX服务器，并从借来的种子主机上迁移出刚刚迁移的VM vmotion。当迁移主机到下一个数据中心时，这个主机将被发送到其他站点作为它们的种子单元。一旦运行和分析了容量计划器，这个初始计划将被修改。
例2:盒子里的办公室
作者最早的问题之一是一家希望使用ESX将数百个远程位置使用ESX易于使用的，并使用作为VM运行的远程Office服务器运行ESX的单个主机的一个易于使用的。由于远程办公室目前使用过时的硬件，因此客户还觉得他应该使用ESX，因为它会提供更好的远程管理能力。客户还认为，硬件应在全球这些远程办事处升级。他们的目标是将一个盒子运到远程位置，它插入，上电，然后远程管理服务器。如果有某种机器故障，他们会发出一个新盒子。关注客户的初始配置是框的初始配置以及如何适当地执行备份。
我们问客户的第一个问题是，他们现在或将来是否会使用微软的ESX集群。当我们第一次开始讨论时，他们声称这是不可能的。为了以防万一，我们确保他们为自己的六驱动器双处理器机器安装了完整的内存和磁盘，一个额外的双端口以太网卡，一个通过Adaptec卡的外部磁带设备图1.11)，以及为可能的共享系统提供足够的文件系统空间。我们讨论了SAN和VMotion的使用，但客户认为这对他们的远程办公室来说太过了。对于他们的数据中心来说，这是必要的，但对于远程办公室来说不是。
办公室在盒服务器带磁带库
然而，最完美的计划被错误地实现了，在最初确认客户的设计一年后，他们需要将Microsoft Clustering实现为一个框中的集群。由于这种疏忽，客户不得不重新安装所有ESX服务器来分配一个小型共享模式VMFS。他们不得不重新安装他们的机器，但首先他们将操作系统磁盘设置为RAID 1，利用磁盘1和磁盘2之间的硬件镜像，将最后4个磁盘留作RAID 5 + 1的146GB磁盘的备用配置。较小的磁盘很好地满足了它们的VM负载。在RAID 5 LUN上，他们创建了两个文件系统，一个用于公共(非集群)虚拟机的VMFS，另一个较小的分区用于集群的共享数据驱动器。
尽管出于lun锁定的考虑，通常不建议对两个不同的vmfs使用单个分区，但正如我们正在讨论的，可以并且已经在单个主机环境中这样做了。如果是入门级SAN(请参考图1.8)，则会添加另一个主机，而多分区方法则会不由于SCSI预留的性质，这是一个最佳实践，这将在第5章中进一步讨论。但是，在单主机配置中，SCSI预留问题不大，因此在同一个LUN上使用多个分区并不违反任何最佳实践。理想情况下，应该有三个lun: RAID 1用于操作系统，RAID 5用于两个必要的vmfs。但是，3个lun至少需要8个磁盘，并且需要一个磁盘阵列，这增加了成本，但没有多少收益，因为所讨论的虚拟机在数量和大小上都很小。
例子3:最新的和最好的
我们的机会之一是满足客户在ESX服务器上使用最新、最好的硬件的需求，同时为下一个操作系统版本制定计划。客户决定采用一个使用双CPU刀片，没有磁盘和许多TOE卡的全刀片框，这样他们就可以通过iSCSI从NAS启动他们的ESX服务器。客户还需要一种更简单和自动化的方式来部署他们的ESX服务器。
这在一开始就提出了几个挑战。第一个挑战是OS的下一个版本当时还没有准备好，当前版本的HCL也没有准备好和下一个版本的ESX的第一个版本显示了他们想要的一些选项不被执行。因此，要使用ESX，需要对ESX 2.5版和3.0版的硬件组合进行更改。因此，客户将TOE卡换成了纤维卡或空白卡。他们还意识到iSCSI和NAS在ESX 3.0的第一个版本中得到有限的支持。因此，它们还需要访问本地磁盘来实现所需的虚拟化。
这里主要关注的是，客户想要最新，最伟大的，而是让一个与当前释放不兼容的好吃的东西，以及下一个版本的HCL的初级未列出其所需的硬件。从本质上讲，如果现在没有在HCL上，最有可能在未来的名单上;如果您可以获得Prerelease HCL，可以验证这一点。从本质上讲，这位客户必须根据发布时间表改变他们的计划，它为客户提供了相当多的头痛，所以需要重新设计，包括使用车载SCSI驱动器和使用SAN的使用。实质上，在购买任何内容之前，始终检查VMware网站上的HCL。
在ESX的部署方面，车载远程管理卡和多种部署ESX的方法使工作更加轻松。因为这些概念已经在其他地方介绍过了，所以我们没有深入讨论很多细节。ESX为刀片服务器提供了自己的脚本安装方法。许多供应商还提供了在刀片服务器上安装操作系统的脚本机制。使用脚本进行安装的关键是添加ESX之外通常需要的所有额外位，包括硬件代理和其他必要的软件。
示例4:SAN
我们的第四个例子是一名客户，他们在使用供应商提供的小型SAN的竞争产品之间咨询咨询。最终，客户在其生产环境中做出了选择并实现了烘焙的结果，这些生产环境使用完全不同的SAN的功能差异。虽然在烘烤期间提供了这些信息，但它几乎是一个脚注。这反过来导致他们如何在必须重新入住的生产中实施ESX的问题。是什么使得这位客户独特的是，他们希望在使用ESX 2.5时获得ESX 3.0样式功能。虽然是一个崇高的目标，但它导致在不遵循最佳实践的模式下设置2.5，但这是可支持的。客户希望将所有VM数据存储在SAN上，包括VM配置和日志文件。客户编写了他们的愿望，并希望确认这是一个可靠的选择。
架构决定呼吁每个ESX服务器挂载一个主目录从圣这VM配置文件可以存储在圣,因为VMFS已经在圣,一切相关的存储在SAN上的VM将使用两个截然不同的文件系统。为了启用多个基于san的文件系统，对于3.0之前的ESX版本，需要在COS和虚拟机之间共享光纤通道适配器。共享光纤通道适配器不是最佳实践，而且经常会导致问题。为了限制问题，最好每个LUN有一个文件系统。因为客户希望配置文件对每个可能的服务器都可用，所以客户创建了多个共享同一个LUN的Linux ext3文件系统。这也没有遵循每个LUN一个文件系统的最佳实践。但是，它们没有混合文件系统类型，因此没有Linux文件系统与VMFS共享LUN的一部分。这是一件好事，因为当共享Fibre Channel适配器时，VMkernel和Linux内核都可以分别锁定LUN，这将导致SCSI保留和其他SCSI问题。我们将在第五章讨论这些问题。
即使这个客户使用了一些没有遵循最佳实践的功能，这里的示例也要指出，尽管存在最佳实践，但它们并没有定义ESX支持或甚至能够支持什么。我们确认了他们的架构是可支持的，但也指出了最佳实践和可能的问题。许多在ESX 3.0之前的版本中不是最佳实践的项目现在已经成为ESX 3.0的一部分。在这个例子中，ESX 3.0版本在VMFS上集成了VM配置和磁盘文件的存储，而不需要使用多个文件系统和可能有问题的配置。了解ESX的局限性将有助于在各种硬件中使用ESX。
示例5:安全环境
只要安全专家了解ESX如何工作以及为什么这样做是安全的，将ESX放置到安全的环境中是越来越普遍的。然而，在这种情况下，安全专家认为，由于vm共享相同的空气，因此存在风险。虽然我们可以证明事实并非如此，但安全环境的设计必须在这个限制范围内工作。最初的硬件是两台双cpu机器和一个小型SAN，后来当他们证明一切都能正常工作时，他们的大型公司SAN接管了这个设备，然后将其移除。客户还希望安全数据除了使用这些信息的团队人员之外，不让任何人看到。
这提出了几个问题。首先，ESX机器的管理员还必须是安全团队的一部分，拥有适当的公司许可，或者被给予例外，因为任何具有ESX服务器管理员权限的人也可以访问ESX服务器上所有可用的vmdk。第4章“审计、监视和保护”非常详细地介绍了保护您的ESX环境，但是可以这么说，虚拟化有它自己的问题。因为客户想要完全保护他们的数据，所以保持服务控制台、VMotion和VM网络都在它们自己的安全网络上也很重要。我们为什么要保护VMotion ?因为VMotion将通过以太网电缆传递服务器的内存占用，并结合对服务控制台的访问，将给黑客一个VM正在做的一切。如果没有适当的保护，这将是一个相当可怕的情况。
虽然该公司有一个管理使用san来表示安全数据lun的规则，但他们没有关于ESX的这样的政策。从本质上讲，创建一个体系结构是很重要的，该体系结构将所有安全虚拟机保存在它们自己的ESX服务器集上，并将那些不属于安全环境的东西放在另一组ESX服务器上。这使得所有的网络都被外部防火墙隔开，并防止非安全团队成员访问数据。如果需要一个新的安全环境，另一对ESX服务器(因此我们可以使用VMotion vm)将被添加到它们自己的防火墙中。
上述操作可以很容易地在单个ESX服务器上执行，但需要管理员具有适当的企业许可，以便允许操作安全文件。考虑到这一点和ESX内部适当的网络配置，可以在单个ESX主机中创建许多不同的安全环境，包括访问ESX外部的其他安全机器。但是，这个客户没有选择这个选项。
例6：灾难恢复
我们被要求为一个客户做一个容灾计划，该客户有两个数据中心，彼此之间距离很近。客户需要每个站点上所有内容的副本集，以便在必要时可以远程运行。这并不是一个不常见的愿望，因为他们实际上想要一个热站点实现。他们当前的ESX服务器负载是在每个位置上的两个双cpu主机，两个完全不同的san和一些略微不同的操作过程。每个ESX服务器上当前较轻的负载最终会增长，直到新机器被放置到环境中。
由于不同的SAN环境，不可能创建数据的SAN副本，因为SAN使用不同的语言。因此，用硬件解决这个问题是不可能的。这反过来又导致了必须解决的政治问题。一旦允许继续，就决定使用其他机制创建备份，并使用某种形式的自动化脚本将vm从一个站点复制到另一个站点。尽管已经有很多工具可以做到这一点，但ESX自带了必要的脚本，可以在虚拟机仍在运行时对其进行备份，因此从本质上讲，ESX只需编写一些脚本就可以制作热拷贝。将其绑定到本地磁带驱动器(客户也希望将其放入混合驱动器中)，就会出现一个强大的本地和远程备份解决方案。
还讨论了其他各种方法，但不幸的是，它们都不起作用。一个关键的想法是使用VMotion，但所涉及的距离意味着虚拟机将通过一个非常长的专用线路从一个站点运送到另一个站点，这将使虚拟机的内存占用处于危险之中。早期版本的ESX通过不允许VMotion通过网关和路由器工作来解决这个问题。另一方面，ESX版本3允许VMotion通过路由器和网关工作。另一种可能是使用异地备份存储库，但这会使恢复变慢。