当评估结束时，您可以更好地判断可以迁移哪些机器并且无法迁移。幸运的是，客户严格“每台机器申请”规则，并强制执行，并删除可能的应用冲突和移民问题。随着详细信息，释放了他们当前的基础架构，可以确定必要的硬件已经在使用中，并且可以使用轻微的硬件升级重用。每台机器都需要双端口NIC和光纤通道卡，并增加内存和本地磁盘空间。要运行所需的虚拟机数量并启用使用vMotion，所有计算机至少将至少在每个站点配对，并且进一步的建议购买每个网站的另一台机器（因为没有更多的主机重用）方便，使他们可以减轻未来可能的机器故障。为了执行第一个迁移，一些种子单位将从他们自己的SAN中雕刻的制造商和LUN借用，允许使用种子单位从物理到虚拟迁移。然后物理主机将被转换为ESX服务器，并且刚刚迁移的VM VMOTioned Off借用的种子主机。当时间来迁移下一个数据中心时，此主机将作为种子单元发送到其他站点。一旦运行并分析了容量计划者，将修改此初始计划。
例2：在一个盒子里的办公室
作者最早提出的一个问题来自一家公司，该公司希望使用ESX将数百个远程位置压缩为一个易于使用和管理的包，该包由一台运行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 5的RAID 1，对于必要的VMFS。但是，三个LUN需要至少八个磁盘，并且磁盘阵列将是必要的，因此增加了不多增益的费用，因为所讨论的VM数量较小，数量较小。
例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上，很可能将来也不会在名单上；如果你能得到预释放HCL，这是可以验证的。本质上，该客户必须根据发布计划更改其计划，这给客户带来了不少麻烦，需要重新设计才能开始，包括使用板载SCSI驱动器和SAN。本质上，在购买任何产品之前，请始终查看VMware网站上的HCL。
在ESX的部署方面，车载远程管理卡和多种部署ESX的方法使工作更加轻松。因为这些概念已经在其他地方介绍过了，所以我们没有深入讨论很多细节。ESX为刀片服务器提供了自己的脚本安装方法。许多供应商还提供了在刀片服务器上安装操作系统的脚本机制。使用脚本进行安装的关键是添加ESX之外通常需要的所有额外位，包括硬件代理和其他必要的软件。
示例4:SAN
我们的第四个示例是一位客户，他引入了咨询服务，使用供应商提供的小型SAN在竞争产品之间进行烘焙。最终，客户做出了选择，并在其生产环境中实施了烘焙的结果，该生产环境使用了完全不同的SAN，在功能上有一些显著差异。虽然这些信息在烘焙期间可用，但它几乎只是一个脚注。这反过来又导致了他们如何在生产中实施ESX的问题，这些问题必须重新设计。该客户的独特之处在于，他们希望在使用ESX 2.5时获得ESX 3.0风格的功能。虽然这是一个崇高的目标，但它导致在一种不遵循最佳实践但可支持的模式下设置2.5。客户希望在SAN上存储所有VM数据，包括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如何工作以及为什么要安全地，它越来越常见于安全环境。但是，在这种情况下，安全专家认为，因为VMS共享相同的空气，因此它们处于风险。虽然我们可以证明不是这种情况，但安全环境的设计必须在这个限制内工作。初始硬件是两个双CPU机器和一个小型SAN，后来将被证明工作的一切工作，并且他们的大型企业SAN接管了。客户还希望任何人都不会对任何人都能看到安全数据，除了团队中的人员使用这些信息。
这提出了几个问题。首先是ESX盒的管理员也必须是安全团队的一部分，具有适当的企业间隙，或者被给出一个例外，因为管理员访问ESX服务器的任何人都可以访问可用的所有VMDKESX服务器。第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通过路由器和网关工作。另一种可能是使用异地备份存储库，但这会使恢复变慢。