如何提高VMware虚拟化的性能
通过把应用整合在一个单一的系统上，Vmware虽然节约了成本，提高了灵活性并且加强了应用管理，但这些是有代价的。本文的目的就是想通过测试来看看，虚拟化在哪些地方会影响系统性能，以及如何尽可能地减少这些影响。
虚拟化的价值与代价
在对VMware Infrastructure 3 Suite的测试中，我们发现VMware ESX Server 会导致不少于10％的性能损耗，最高能达到20％。我们不是说VMware会让系统运行起来磕磕绊绊——硬件虚拟化确实是一种不错的方法，可以帮助你简化服务器整合的复杂度，节约成本和能耗，而且只要有正确的规划，也还是能避免一定程度的性能损耗。但不管怎样，性能损耗总是会存在的。
在波士顿合作伙伴的实验室里，我们的测试发现，运行ESX Server最主要的好处无疑就是能通过多个虚拟服务器运行多个应用程序，从而最大限度的利用现有的硬件资源。这一点对于硬件厂商来说，却是一种噩梦：Gartner预测这项技术可能导致x86服务器的年复合增长率到2010年会降低0.6个百分点。
虚拟化的价值与风险
而且，有意思的是，当我们最近问读者他们觉得哪项技术最没前途，虚拟化居然排到了第二，就在SOA的后面。20%的受访者表示还没有认识到厂商们宣传的虚拟化好处。
虚拟化好处的用户调查
当然，我们仍然认为虚拟化技术是一件好事。不管你是用Microsoft Virtual Server、VMware、Xen还是其它的软件，虚拟化技术确实有许多好处——从更好的利用物理设备到改善应用管理，以及在多台机器之间分配资源的能力等等。使用虚拟机，把老的应用从旧硬件迁移到可靠性和可用性更高的新系统上，可以大大减少物理服务器的数量。通过测试，我们发现了一些方法，可以增强虚拟化技术的价值，减少性能损耗。
在具体探讨性能影响问题之前，我们先来看看虚拟化在服务器整合、系统管理、软硬件兼容、虚拟机与应用迁移，以及资源分配等方面的一些价值、代价和注意事项。
1）“把所有鸡蛋都放在一个篮子里”所带来的风险
在一台物理服务器上运行多个虚拟机，跟每台物理服务器运行一个应用相比，硬件故障会影响更多的应用。但对多数情况，冒这种风险还是值得的。对于拥有过多服务器的小型数据中心而言，通过整合可以减少服务器数量，从而有利于控制机房空间成本和散热成本。但是，一旦数据中心断电或发生火灾，这种整合也会影响到更多的应用。因此，如果你要使用虚拟化技术，最好有一些冗余设施来尽量降低风险。
2）虚拟化增强了系统与应用管理的灵活性
在系统管理方面，虚拟化提供了一个具有移动性和灵活性的隔离层，能帮助IT工程师做好硬件维护、排除硬件障碍，做好应用支持，提高应用管理的性能。比如，象VMware这样的虚拟化环境可以提供它自己的虚拟硬件和BIOS，来支持操作系统和应用程序。这使得管理员把某个应用迁移到另一个系统上更加容易——应用很少受到硬件兼容性问题的干扰，因为所有的虚拟硬件都是相同的。具体来说，就是简化了日常维护。如果某台服务器要下线，只要把那台服务器上的所有虚拟机迁移到另一台运行虚拟机环境的服务器上去就可以了，应用不会被中断。
3）注意软硬件的兼容性问题
在应用软件的技术支持方面，只要软件厂商支持自己的软件运行在虚拟环境中，一般硬件相关的兼容性问题是可以避免的，但不是所有的都可以避免，因为一些应用和整合后的存储设备（如iSCSI和SAN子系统）之间存在一定的耦合关系。这就需要在虚拟环境中安装一些特定的驱动程序，并得到厂商的技术支持。
4）虚拟机可灵活迁移，但增加管理成本
虚拟机的移动性也使得IT管理人员在把一个应用从某台服务器迁移到另一台上时更加容易，这种能力有助于IT环境动态、灵活地适应业务需求。比如，某台服务器运行了4个虚拟机，但有一台虚拟机上的应用需求突然增加了，使得服务器无法继续支持这一应用。于是，管理人员就可以把这个应用迁移到一个性能更强大的系统上去，或者把其他虚拟机迁移到其它服务器上去以释放资源。
但是，这会增加虚拟机镜像的管理成本。为了获得真正可移植的环境，以便虚拟机在系统间迁移或者从灾难性硬件故障中恢复，企业必须购买一些特殊的工具，如altiris的部署解决方案。另外，他们还必须保证虚拟机镜像的实时更新，了解网络和存储的拓扑结构，以便当一个虚拟机迁移到另外一台服务器上时，还能有效地访问存储子系统。
5）尽量确保虚拟机之间不会争抢资源
总的来说，通过创建虚拟硬件，ESX Server使得IT工程师能够在同一套物理环境中安装多个操作系统。关键在于，要确保运行在这些虚拟机上的应用不会互相冲突而降低应用性能，只有这样，才能最大化的利用硬件资源。
虚拟机性能影响：磁盘、内存和CPU
我们的测试环境是两台Dell PowerEdge 2850服务器。这两台服务器的配置一样，都是两个Intel Xeon双核CPU、2GB内存和三块硬盘的RAID阵列。Xeon处理器含有Intel VT虚拟化技术，提供了CPU虚拟化的代码优化。然后，我们运行了三种应用——微软Exchange Server 2003、SQL Server 2005和IIS（Internet信息服务），并采用了一些免费和商业性的工具软件，包括微软Exchange Server 2003负载模拟器（LoadSim）、SQLIOSim以及Borland的SilkPerformer 2006 R2。
从根本上来说，跟直接在物理服务器上运行某一应用相比，在基于同一物理平台的虚拟机上跑同一应用，一定会产生性能上的损耗。在我们的测试中，这种损耗随应用的不同而变化，但一般少于10％，在6％-20％之间。
1）磁盘问题
跟一般企业的实际应用不同，我们的测试环境中没有专门的存储子系统，如为特定应用存放数据的SAN。对于Exchange这样的应用，SAN不仅仅是提供数据存储和数据管理，也可以防止资源冲突，如当操作系统和应用程序要同时访问虚拟内存和磁盘的时候。因此，如果有一个专门的存储子系统，就能减少这样的资源冲突。另外，在同时运行多个虚拟机时，还要看应用是否需要持续的访问磁盘。
在用LoadSim测试Exchange和用SQLIOSim测试SQL Server时，都有频繁的磁盘读写操作，但Exchange Server 2003和SQL Server 2005的性能仅降低了6％。这一结果说明，在虚拟机不会争抢访问磁盘的情况下，虚拟化对那些主要依赖驱动性能的应用影响并不大。
ESX Server不支持动态分配磁盘空间，除非添加存储设备。从实际应用的角度来看，这确实是个棘手的问题。在决定某一台服务器上能运行多少个虚拟机时，一个关键因素可能就是包含磁盘空间的虚拟机镜像的大小。在默认情况下，ESX Server为一台虚拟机分配的磁盘空间是4GB。在测试中，为了保证有足够的空间安装应用程序和后续软件升级，我们给虚拟机分配的最小空间是10GB。而我们的系统总共有128GB的磁盘空间，因此可以安装10个虚拟机。
值得注意的是，随着应用负载的变化，性能表现也会随之变化，有时我们不得不考虑把一个虚拟机从服务器上删除。但问题在于，在虚拟机移除之后，新释放出来的磁盘空间因为性能问题无法再分配给其它虚拟机使用，这些空间也就被闲置了。
我们的测试结果表明，要想在同一套硬件系统上运行多个需要大量磁盘操作的应用时，就不要指望特别好的性能了，除非每个应用的数据存放在特定的存储子系统，如SAN。比如在同一套硬件系统上组合运行微软 Exchange Server 2003和SQL Server 2005时，如果两者都进行频繁的磁盘操作，性能就很一般，而如果Exchange更多使用磁盘子系统，而SQL Server更多使用内存时，性能表现就要好得多。
如果你计划动态地迁移虚拟机时，一定要考虑好存储的问题。比如，当一个应用不再需要时，你会考虑把一个虚拟机删除，但问题在于，当你要想把另一个应用迁移到这台服务器上时，你可能会发现，虚拟机的镜像太大了。
2）内存问题
就我们的测试而言，ESX Server的损耗主要还是来自系统内存和处理性能上。为了充分利用现有的硬件资源，我们考虑把内存资源进行划分，因为在理论上，现有的内存没有被充分利用。比如，服务器上的某个应用只使用了2GB总内存容量中的512MB，对2.8 GHz CPU的占用率也只有25%。如果把这个应用迁移到VMware ESX Server上，并为其分配512MB内存和700 MHz CPU，我们还有余下的资源可以分配给其他应用。基于这种考虑，我们在测试也根据应用的需求不同对2GB内存进行了划分——比如，SQL Server至少需要1GB内存，而Exchange Server 2003需要512MB内存就够了。
VMware有内存页面共享技术，可以让VI3分配至少两倍于物理内存的虚拟内存。在你打算整合那些分散在各个物理服务器上，却又不常用的应用时，如文件和打印服务，这项技术就比较有用了。在一台服务器上可以运行10个虚拟机，而这些应用同时需要CPU和内存资源的可能性又比较小，即使同时运行，性能低一点也是可以忍受的。
不过，在用SilkPerformer 2006测试IIS性能时发现，局域网性能受到了较大的影响——hits per second下降了18％，kilobits per second也下降了20%。这说明，跟SQL Server和Exchange不同，在把应用从一个有2GB内存的主机迁移到一个只有512MB内存的虚拟机上时，要付出相当的代价——内存减少比磁盘操作增多对性能的影响更大。
当然，为虚拟机增加内存，就能使局域网应用测试的性能提高。把内存从512MB增加到1GB，能提高10％的吞吐量，性能损失也能从20％降到12％。可见，对于那些内存消耗比较多的应用，给虚拟机分配尽可能多的物理内存是有好处的。
不过，并不是在所有情况下增加资源都能提高性能。比如在测试中给虚拟机多加一块虚拟网卡就不能提升性能；在测试SQL Server时增加内存，也没能提高性能，因为它测试的主要是磁盘操作。
3）CPU问题
我们的测试平台包含两个双核的2.7GHz 64位Xeon处理器。不过，ESX Server只能让我们按32位的处理方式来分配CPU，这意味着虽然ESX Server可以执行64位代码来管理虚拟机环境，但虚拟机只能运行32位操作系统和应用程序。值得注意的是，ESX Server能支持64位操作系统，你可以在Vmware下部署64位应用。然而，在32位的Windows Server 2003上运行32位应用程序时，ESX Server只能按32位处理方式分配CPU。当我们试着安装64位的Windows Server 2003时，Windows能检测到这个虚拟CPU也只是32位的。
此外，可用的资源还包括实际的CPU MHz。理论上，我们可以在虚拟机之间任意划分CPU时钟周期。处理器数量也可以更加灵活，如两个双核处理器在理论上就有四个可供分配的处理器。
在测试中，我们用两个虚拟机平分4.7GHz的处理能力，在这种配置下，内存密集型测试的性能下降了4％-7％。然后我们把3 GHz的处理能力分配给SQLIOSim，把剩下的1.7GHz给LoadSim，发现性能又回到了原先没有资源竞争时的那个水平。
ESX Server通过Virtual Infrastructure Client，使用相同的接口和方式来分配CPU和系统内存。在分配CPU处理能力时，可以按可用频率的百分比、或具体的频率值来划分，也可以按可用处理器的个数来划分。在分配内存时，可以按可用内存的百分比、或具体内存大小来划分。
其他一些值得注意的问题
虽然VMware提供了工具帮助管理应用性能，但在迁移到ESX Server之前我们还是要多花些时间评估性能需求。不仅要看某个应用需要多少资源，还要看它在峰值运算时的概况。
在部署虚拟化时，一种常见的应用是在一个虚拟机上运行邮件服务器，而另一个虚拟机上运行文件/打印服务器。但问题在于，如果在下班时有许多人下载邮件、打印大文档带回家看、或者备份文件，这时这些虚拟机性能就会变得很慢，因为会争抢系统资源。
用来管理虚拟机镜像的Virtual Infrastructure Client有一套工具可以监视虚拟机的性能，但缺乏根据需要自动配置资源的能力。而ESX Server在某个虚拟机的CPU率利用过高时，可以自动地从那些闲散的虚拟机上分出一部分资源来给它用。
另一个值得注意的是，要关注某个特定应用的资源需求变化。因为，随着时间的推移，有些应用会变得越来越重要，工作负载越来越重，而另一些应用可能不再象以前那么重要，负载也越来越轻。在这种情况下，需要虚拟机有自动适应的能力，如VMware Virtual Infrastructure 3就能够根据资源需求变化把虚拟机迁移到不同的硬件平台上去。如果某台虚拟机影响了另一台虚拟机的性能，你也可以轻轻松松地把它迁移到另一台服务器上去。象Altiris提供的第三方工具也有能创建虚拟机镜像，从而简化按需增加更多计算资源的操作。
最后，只要你愿意花时间去分析应用性能的变化，使用VMware Virtual Infrastructure 3中的ESX Server来做虚拟化，就可以实现服务器硬件资源的最大化利用。要用虚拟机把需要不同资源的应用整合到一台服务器上，这样他们才不会争抢稀缺资源。
在评估性能和管理虚拟机环境时，我们还碰到了一些轻微的性能问题。
1) 在测试中，依靠秒表而不是系统时钟，因为虚拟机显示的时间不一定准确，在测试中有5-10秒的误差，如我们在运行SQLIOSim测试时，发现屏幕右下角的系统时钟总落后于手工测算的时间。
2)在管理虚拟机上的应用时，要注意网络性能的影响。尽管VMware已经做了大量的工作来优化Virtual Infrastructure Client远程控制台工具的显示效果，但我们还是发现性能会受一定影响。运行LoadSim测试时，每次运行结束时要停止存储子系统，删除临时的用户帐号，删除日志文件和重新装载Exchange的邮件存放目录。一般情况下，这些任务大概只要10分钟就能做完，但在虚拟机上要花20分钟，因为要等待控制台刷新。
3)留足时间做部署。我们发现一些基本的虚拟机设置同样令人痛苦。因此，那些帮助你快速设置、部署虚拟机以及安装应用的管理工具还是值得花钱去买的。
综上所述，我们看到，虚拟化所产生的性能损耗是无法完全消除的。根据应用不同以及应用所需的资源不同（如有磁盘密集型、内存密集型或CPU密集型），性能表现也会不同。为了获得令人满意的应用效果，我们建议：1）要预测虚拟化带来的性能损耗；2）不要指望虚拟硬件资源能比物理硬件带来更多的价值；3）把对资源需求不同的应用分到一组，放在同一套硬件上；4）使用VMware的工具来优化资源的使用；5）采用VMware或第三方工具，使得虚拟机更容易被迁移到其它硬件平台。
虚拟化的价值与代价
在对VMware Infrastructure 3 Suite的测试中，我们发现VMware ESX Server 会导致不少于10％的性能损耗，最高能达到20％。我们不是说VMware会让系统运行起来磕磕绊绊——硬件虚拟化确实是一种不错的方法，可以帮助你简化服务器整合的复杂度，节约成本和能耗，而且只要有正确的规划，也还是能避免一定程度的性能损耗。但不管怎样，性能损耗总是会存在的。
在波士顿合作伙伴的实验室里，我们的测试发现，运行ESX Server最主要的好处无疑就是能通过多个虚拟服务器运行多个应用程序，从而最大限度的利用现有的硬件资源。这一点对于硬件厂商来说，却是一种噩梦：Gartner预测这项技术可能导致x86服务器的年复合增长率到2010年会降低0.6个百分点。
虚拟化的价值与风险
而且，有意思的是，当我们最近问读者他们觉得哪项技术最没前途，虚拟化居然排到了第二，就在SOA的后面。20%的受访者表示还没有认识到厂商们宣传的虚拟化好处。
虚拟化好处的用户调查
当然，我们仍然认为虚拟化技术是一件好事。不管你是用Microsoft Virtual Server、VMware、Xen还是其它的软件，虚拟化技术确实有许多好处——从更好的利用物理设备到改善应用管理，以及在多台机器之间分配资源的能力等等。使用虚拟机，把老的应用从旧硬件迁移到可靠性和可用性更高的新系统上，可以大大减少物理服务器的数量。通过测试，我们发现了一些方法，可以增强虚拟化技术的价值，减少性能损耗。
在具体探讨性能影响问题之前，我们先来看看虚拟化在服务器整合、系统管理、软硬件兼容、虚拟机与应用迁移，以及资源分配等方面的一些价值、代价和注意事项。
1）“把所有鸡蛋都放在一个篮子里”所带来的风险
在一台物理服务器上运行多个虚拟机，跟每台物理服务器运行一个应用相比，硬件故障会影响更多的应用。但对多数情况，冒这种风险还是值得的。对于拥有过多服务器的小型数据中心而言，通过整合可以减少服务器数量，从而有利于控制机房空间成本和散热成本。但是，一旦数据中心断电或发生火灾，这种整合也会影响到更多的应用。因此，如果你要使用虚拟化技术，最好有一些冗余设施来尽量降低风险。
2）虚拟化增强了系统与应用管理的灵活性
在系统管理方面，虚拟化提供了一个具有移动性和灵活性的隔离层，能帮助IT工程师做好硬件维护、排除硬件障碍，做好应用支持，提高应用管理的性能。比如，象VMware这样的虚拟化环境可以提供它自己的虚拟硬件和BIOS，来支持操作系统和应用程序。这使得管理员把某个应用迁移到另一个系统上更加容易——应用很少受到硬件兼容性问题的干扰，因为所有的虚拟硬件都是相同的。具体来说，就是简化了日常维护。如果某台服务器要下线，只要把那台服务器上的所有虚拟机迁移到另一台运行虚拟机环境的服务器上去就可以了，应用不会被中断。
3）注意软硬件的兼容性问题
在应用软件的技术支持方面，只要软件厂商支持自己的软件运行在虚拟环境中，一般硬件相关的兼容性问题是可以避免的，但不是所有的都可以避免，因为一些应用和整合后的存储设备（如iSCSI和SAN子系统）之间存在一定的耦合关系。这就需要在虚拟环境中安装一些特定的驱动程序，并得到厂商的技术支持。
4）虚拟机可灵活迁移，但增加管理成本
虚拟机的移动性也使得IT管理人员在把一个应用从某台服务器迁移到另一台上时更加容易，这种能力有助于IT环境动态、灵活地适应业务需求。比如，某台服务器运行了4个虚拟机，但有一台虚拟机上的应用需求突然增加了，使得服务器无法继续支持这一应用。于是，管理人员就可以把这个应用迁移到一个性能更强大的系统上去，或者把其他虚拟机迁移到其它服务器上去以释放资源。
但是，这会增加虚拟机镜像的管理成本。为了获得真正可移植的环境，以便虚拟机在系统间迁移或者从灾难性硬件故障中恢复，企业必须购买一些特殊的工具，如altiris的部署解决方案。另外，他们还必须保证虚拟机镜像的实时更新，了解网络和存储的拓扑结构，以便当一个虚拟机迁移到另外一台服务器上时，还能有效地访问存储子系统。
5）尽量确保虚拟机之间不会争抢资源
总的来说，通过创建虚拟硬件，ESX Server使得IT工程师能够在同一套物理环境中安装多个操作系统。关键在于，要确保运行在这些虚拟机上的应用不会互相冲突而降低应用性能，只有这样，才能最大化的利用硬件资源。
虚拟机性能影响：磁盘、内存和CPU
我们的测试环境是两台Dell PowerEdge 2850服务器。这两台服务器的配置一样，都是两个Intel Xeon双核CPU、2GB内存和三块硬盘的RAID阵列。Xeon处理器含有Intel VT虚拟化技术，提供了CPU虚拟化的代码优化。然后，我们运行了三种应用——微软Exchange Server 2003、SQL Server 2005和IIS（Internet信息服务），并采用了一些免费和商业性的工具软件，包括微软Exchange Server 2003负载模拟器（LoadSim）、SQLIOSim以及Borland的SilkPerformer 2006 R2。
从根本上来说，跟直接在物理服务器上运行某一应用相比，在基于同一物理平台的虚拟机上跑同一应用，一定会产生性能上的损耗。在我们的测试中，这种损耗随应用的不同而变化，但一般少于10％，在6％-20％之间。
1）磁盘问题
跟一般企业的实际应用不同，我们的测试环境中没有专门的存储子系统，如为特定应用存放数据的SAN。对于Exchange这样的应用，SAN不仅仅是提供数据存储和数据管理，也可以防止资源冲突，如当操作系统和应用程序要同时访问虚拟内存和磁盘的时候。因此，如果有一个专门的存储子系统，就能减少这样的资源冲突。另外，在同时运行多个虚拟机时，还要看应用是否需要持续的访问磁盘。
在用LoadSim测试Exchange和用SQLIOSim测试SQL Server时，都有频繁的磁盘读写操作，但Exchange Server 2003和SQL Server 2005的性能仅降低了6％。这一结果说明，在虚拟机不会争抢访问磁盘的情况下，虚拟化对那些主要依赖驱动性能的应用影响并不大。
ESX Server不支持动态分配磁盘空间，除非添加存储设备。从实际应用的角度来看，这确实是个棘手的问题。在决定某一台服务器上能运行多少个虚拟机时，一个关键因素可能就是包含磁盘空间的虚拟机镜像的大小。在默认情况下，ESX Server为一台虚拟机分配的磁盘空间是4GB。在测试中，为了保证有足够的空间安装应用程序和后续软件升级，我们给虚拟机分配的最小空间是10GB。而我们的系统总共有128GB的磁盘空间，因此可以安装10个虚拟机。
值得注意的是，随着应用负载的变化，性能表现也会随之变化，有时我们不得不考虑把一个虚拟机从服务器上删除。但问题在于，在虚拟机移除之后，新释放出来的磁盘空间因为性能问题无法再分配给其它虚拟机使用，这些空间也就被闲置了。
我们的测试结果表明，要想在同一套硬件系统上运行多个需要大量磁盘操作的应用时，就不要指望特别好的性能了，除非每个应用的数据存放在特定的存储子系统，如SAN。比如在同一套硬件系统上组合运行微软 Exchange Server 2003和SQL Server 2005时，如果两者都进行频繁的磁盘操作，性能就很一般，而如果Exchange更多使用磁盘子系统，而SQL Server更多使用内存时，性能表现就要好得多。
如果你计划动态地迁移虚拟机时，一定要考虑好存储的问题。比如，当一个应用不再需要时，你会考虑把一个虚拟机删除，但问题在于，当你要想把另一个应用迁移到这台服务器上时，你可能会发现，虚拟机的镜像太大了。
2）内存问题
就我们的测试而言，ESX Server的损耗主要还是来自系统内存和处理性能上。为了充分利用现有的硬件资源，我们考虑把内存资源进行划分，因为在理论上，现有的内存没有被充分利用。比如，服务器上的某个应用只使用了2GB总内存容量中的512MB，对2.8 GHz CPU的占用率也只有25%。如果把这个应用迁移到VMware ESX Server上，并为其分配512MB内存和700 MHz CPU，我们还有余下的资源可以分配给其他应用。基于这种考虑，我们在测试也根据应用的需求不同对2GB内存进行了划分——比如，SQL Server至少需要1GB内存，而Exchange Server 2003需要512MB内存就够了。
VMware有内存页面共享技术，可以让VI3分配至少两倍于物理内存的虚拟内存。在你打算整合那些分散在各个物理服务器上，却又不常用的应用时，如文件和打印服务，这项技术就比较有用了。在一台服务器上可以运行10个虚拟机，而这些应用同时需要CPU和内存资源的可能性又比较小，即使同时运行，性能低一点也是可以忍受的。
不过，在用SilkPerformer 2006测试IIS性能时发现，局域网性能受到了较大的影响——hits per second下降了18％，kilobits per second也下降了20%。这说明，跟SQL Server和Exchange不同，在把应用从一个有2GB内存的主机迁移到一个只有512MB内存的虚拟机上时，要付出相当的代价——内存减少比磁盘操作增多对性能的影响更大。
当然，为虚拟机增加内存，就能使局域网应用测试的性能提高。把内存从512MB增加到1GB，能提高10％的吞吐量，性能损失也能从20％降到12％。可见，对于那些内存消耗比较多的应用，给虚拟机分配尽可能多的物理内存是有好处的。
不过，并不是在所有情况下增加资源都能提高性能。比如在测试中给虚拟机多加一块虚拟网卡就不能提升性能；在测试SQL Server时增加内存，也没能提高性能，因为它测试的主要是磁盘操作。
3）CPU问题
我们的测试平台包含两个双核的2.7GHz 64位Xeon处理器。不过，ESX Server只能让我们按32位的处理方式来分配CPU，这意味着虽然ESX Server可以执行64位代码来管理虚拟机环境，但虚拟机只能运行32位操作系统和应用程序。值得注意的是，ESX Server能支持64位操作系统，你可以在Vmware下部署64位应用。然而，在32位的Windows Server 2003上运行32位应用程序时，ESX Server只能按32位处理方式分配CPU。当我们试着安装64位的Windows Server 2003时，Windows能检测到这个虚拟CPU也只是32位的。
此外，可用的资源还包括实际的CPU MHz。理论上，我们可以在虚拟机之间任意划分CPU时钟周期。处理器数量也可以更加灵活，如两个双核处理器在理论上就有四个可供分配的处理器。
在测试中，我们用两个虚拟机平分4.7GHz的处理能力，在这种配置下，内存密集型测试的性能下降了4％-7％。然后我们把3 GHz的处理能力分配给SQLIOSim，把剩下的1.7GHz给LoadSim，发现性能又回到了原先没有资源竞争时的那个水平。
ESX Server通过Virtual Infrastructure Client，使用相同的接口和方式来分配CPU和系统内存。在分配CPU处理能力时，可以按可用频率的百分比、或具体的频率值来划分，也可以按可用处理器的个数来划分。在分配内存时，可以按可用内存的百分比、或具体内存大小来划分。
其他一些值得注意的问题
虽然VMware提供了工具帮助管理应用性能，但在迁移到ESX Server之前我们还是要多花些时间评估性能需求。不仅要看某个应用需要多少资源，还要看它在峰值运算时的概况。
在部署虚拟化时，一种常见的应用是在一个虚拟机上运行邮件服务器，而另一个虚拟机上运行文件/打印服务器。但问题在于，如果在下班时有许多人下载邮件、打印大文档带回家看、或者备份文件，这时这些虚拟机性能就会变得很慢，因为会争抢系统资源。
用来管理虚拟机镜像的Virtual Infrastructure Client有一套工具可以监视虚拟机的性能，但缺乏根据需要自动配置资源的能力。而ESX Server在某个虚拟机的CPU率利用过高时，可以自动地从那些闲散的虚拟机上分出一部分资源来给它用。
另一个值得注意的是，要关注某个特定应用的资源需求变化。因为，随着时间的推移，有些应用会变得越来越重要，工作负载越来越重，而另一些应用可能不再象以前那么重要，负载也越来越轻。在这种情况下，需要虚拟机有自动适应的能力，如VMware Virtual Infrastructure 3就能够根据资源需求变化把虚拟机迁移到不同的硬件平台上去。如果某台虚拟机影响了另一台虚拟机的性能，你也可以轻轻松松地把它迁移到另一台服务器上去。象Altiris提供的第三方工具也有能创建虚拟机镜像，从而简化按需增加更多计算资源的操作。
最后，只要你愿意花时间去分析应用性能的变化，使用VMware Virtual Infrastructure 3中的ESX Server来做虚拟化，就可以实现服务器硬件资源的最大化利用。要用虚拟机把需要不同资源的应用整合到一台服务器上，这样他们才不会争抢稀缺资源。
在评估性能和管理虚拟机环境时，我们还碰到了一些轻微的性能问题。
1) 在测试中，依靠秒表而不是系统时钟，因为虚拟机显示的时间不一定准确，在测试中有5-10秒的误差，如我们在运行SQLIOSim测试时，发现屏幕右下角的系统时钟总落后于手工测算的时间。
2)在管理虚拟机上的应用时，要注意网络性能的影响。尽管VMware已经做了大量的工作来优化Virtual Infrastructure Client远程控制台工具的显示效果，但我们还是发现性能会受一定影响。运行LoadSim测试时，每次运行结束时要停止存储子系统，删除临时的用户帐号，删除日志文件和重新装载Exchange的邮件存放目录。一般情况下，这些任务大概只要10分钟就能做完，但在虚拟机上要花20分钟，因为要等待控制台刷新。
3)留足时间做部署。我们发现一些基本的虚拟机设置同样令人痛苦。因此，那些帮助你快速设置、部署虚拟机以及安装应用的管理工具还是值得花钱去买的。
综上所述，我们看到，虚拟化所产生的性能损耗是无法完全消除的。根据应用不同以及应用所需的资源不同（如有磁盘密集型、内存密集型或CPU密集型），性能表现也会不同。为了获得令人满意的应用效果，我们建议：1）要预测虚拟化带来的性能损耗；2）不要指望虚拟硬件资源能比物理硬件带来更多的价值；3）把对资源需求不同的应用分到一组，放在同一套硬件上；4）使用VMware的工具来优化资源的使用；5）采用VMware或第三方工具，使得虚拟机更容易被迁移到其它硬件平台。