我工作的 IT 部门正在尝试迁移到 100% 虚拟化服务器，所有数据都存储在 SAN 上。他们还没有这样做，但该计划最终要求将现有的物理 SQL Server 机器也迁移到虚拟服务器。
几个月前，我参加了 Heroes Happen Here 发布活动，在一次 SQL Server 会议上，演讲者顺便提到这对于生产系统来说不是一个好主意。
所以我正在寻找一些东西：
我可以从个人经验中这么说，因为在我们说话的时候我正在处理这个问题。我目前作为承包商工作的地方为其 SQL Server 开发系统提供了这种类型的环境。我正在尝试在这种环境下开发一个相当适中的 BI 系统，并且确实在努力解决性能问题。
TLB 未命中和模拟 I/O 在幼稚的虚拟机上非常慢。如果您的 O/S 支持准虚拟化（这在 Windows 上仍然不是成熟的技术），那么您可以使用准虚拟化 I/O（本质上是与 VM 中的 API 挂钩的设备驱动程序）。最近版本的 Opteron 支持嵌套页表，这消除了在软件中模拟 MMU 的需要（这真的很慢）。
因此，在大型数据集上运行并执行大量 I/O（例如 ETL 进程）的应用程序会遇到虚拟化的致命弱点。如果您有像数据仓库系统这样的东西，可能会占用内存或磁盘 I/O，您应该考虑其他东西。对于一个简单的事务应用程序，它们可能没问题
从透视角度来看，我正在使用的系统在具有 4 个 2gbit F/C 链接的 SAN 上的刀片（IBM 服务器）上运行。这是一个中档 SAN。VM 有 4GB 的 RAM IIRC，现在有两个虚拟 CPU。在最好的情况下（当 SAN 安静时），这仍然只是我XW9300速度的一半，它在 1 个 U320 总线和 4GB RAM 上有 5 个 SCSI 磁盘（系统、临时数据库、日志、数据、数据）。
您的里程可能会有所不同，但我建议使用工作站系统，例如我描述的用于开发任何 I/O 繁重的工作站系统，而不是 SAN 上的虚拟服务器。除非您的资源使用要求超出了此类工具包（在这种情况下，无论如何它们都远远超出了虚拟服务器），否则这是一个更好的解决方案。硬件并不昂贵——肯定比 SAN、刀片机箱和 VMWare 许可便宜得多。SQL Server 开发者版附带 VS Pro 及更高版本。
这还有一个好处是，您的开发团队不得不从一开始就被迫处理部署——您必须想出一个易于“一键式”部署的架构。这并不像听起来那么难。 Redgate SQL Compare Pro是您的朋友。您的开发人员还将获得数据库管理的基本工作知识。
快速浏览一下惠普的网站，我得到了大约 4,600 美元的 XW8600（他们目前基于至强的型号）的标价，该型号配备四核至强芯片、4GB 内存和 1x146 和 4x73GB 15k SAS 硬盘。街头价格可能会少一些。将此与 SAN、刀片机箱和 VMware 许可的价格以及该设置的备份成本进行比较。对于备份，您可以提供带有备份的网络共享，人们可以根据需要删除压缩的数据库备份文件。
编辑：AMD 网站上的这份白皮书讨论了 VM 上的一些基准测试。从后面的基准测试来看，繁重的 I/O 和 MMU 工作负载确实破坏了 VM 性能。他们的基准测试（由于它是供应商提供的统计数据，因此需要谨慎对待）表明 OLTP 基准测试的速度损失为 3.5 倍。虽然这是供应商提供的，但应牢记：
它对幼稚的虚拟化进行基准测试，并将其与半虚拟化解决方案进行比较，而不是裸机性能。
OLTP 基准测试将具有更多随机访问 I/O 工作负载，并且将花费更多时间等待磁盘寻道。更顺序的磁盘访问模式（数据仓库查询的特征）将有更高的惩罚，并且具有大量 TLB 未命中的内存密集型操作（例如，SSAS 是一个圣经内存猪）也将招致额外的惩罚. 这意味着此类处理的减速可能比白皮书中引用的 OLTP 基准惩罚更为明显。
我们在这里看到的是 TLB 未命中和 I/O 在 VM 上非常昂贵。在 MMU 中具有半虚拟化驱动程序和硬件支持的良好架构将缓解部分或全部这些问题。但是，我认为 Windows Server 2003 根本不支持半虚拟化，而且我不确定 Windows 2008 服务器提供了何种级别的支持。根据我的经验，与相对适中的规格裸机硬件相比，在处理 ETL 流程和 SSAS 多维数据集构建时，VM 会从根本上减慢服务器的速度。
SAN——当然还有集群，但关于虚拟化——你会受到性能影响（对你来说可能值得，也可能不值得）：
http://blogs.technet.com/andrew/archive/2008/05/07/virtualized-sql-server.aspx
http://sswug.org最近在他们的每日通讯中有一些关于它的注释
我想添加 Brent Ozar 的这一系列文章：
在我所希望的意义上，它并不完全具有权威性（来自构建服务器的团队，或某种官方手册），但 Brent Ozar 非常受人尊敬，我认为他在涵盖所有问题方面做得很好.
我们在 VMWare 上为 900 多人运行一个工资系统，没有任何问题。这已经生产了10个月。就 DB 而言，这是一个中等大小的负载，我们在 VM 中预先分配了驱动器空间以防止 IO 问题。您必须定期对 VM 主机和 VM 片进行碎片整理，以保持可接受的性能。
这是一些 VMWARE 测试。 http://www.vmware.com/files/pdf/SQLServerWorkloads.pdf
当然，他们不会将其与物理机器进行比较。但是，您可能可以使用他们用于您的环境的工具进行类似的测试。
我们目前在 VMWARE 环境中运行 SQL Server 2005。但是，它是一个负载非常轻的数据库，而且非常棒。运行没有问题。
正如大多数人所指出的，这将取决于您的数据库负载。
也许你可以说服 IT 部门在盲目实施之前做一些好的测试。
不，我不能指出任何特定的测试或类似的东西，但我可以从经验中说，将生产数据库服务器放在虚拟机上是一个坏主意，尤其是在它有很大负载的情况下。
有利于发展。甚至可能进行测试（理论上，如果它在虚拟盒的负载下运行良好，它会在生产中运行良好）但不是在生产中。
这真的是常识。你想让你的硬件运行两个操作系统和你的 sql server 还是一个操作系统和 sql server？
编辑：我的经验使我的反应有偏差。我曾在沉重的恒定负载下使用大型数据库。如果您在轻负载下拥有较小的数据库，则虚拟化可能适合您。
在Conor Cunningham 的博客文章Database Virtualization - The Dirty Little Secret 没人谈论...中有一些与此相关的信息。去引用：
在服务器本身内部，对于这个领域中对性能很重要的许多事情知之甚少，令人惊讶。SQL Server 的核心引擎假设如下：
- 所有 CPU 都同样强大
- 所有 CPU 以大致相同的速率处理指令。
- 刷新到磁盘可能应该在有限的时间内发生。
这篇文章还进一步详细阐述了这些问题。考虑到总体上考虑到这个问题的可用信息稀缺，我认为这是一本很好的读物。
请注意，有一些专门为数据库设计的虚拟化产品可能值得研究，而不是像 VMWare 这样的通用产品。
我们公司（超过 200 台 SQL 服务器）目前正在我们的一些服务器上部署HP Polyserve：
适用于 Microsoft SQL Server 的 HP PolyServe 软件可以将多个 Microsoft SQL Server 实例整合到数量少得多的服务器和集中式 SAN 存储上。HP PolyServe 独特的“共享数据”架构在实用程序平台中提供企业级可用性和类似虚拟化的灵活性。
我们部署它的主要原因是使硬件更换更容易：将新盒子添加到“矩阵”中，在每个 SQL 实例所在的位置（无缝地）随机排列，然后移除旧盒子。对应用程序团队透明，因为 SQL 实例名称不会更改。
旧问题与旧答案
该线程中的答案已有多年历史。整个线程中的大多数负面观点在技术上仍然是正确的，但相关性要小得多。与过去相比，虚拟化和 SAN 的开销成本现在已不再是一个因素。正确配置的虚拟化主机、来宾、网络和 SAN 可以提供良好的性能以及虚拟化和操作灵活性的好处，包括只有虚拟化才能提供的良好恢复方案。
然而，在现实世界中，只需要一个小的配置细节就可以让整个事情陷入困境。在实践中，虚拟 SQL 服务器的最大挑战是说服负责虚拟化的人员并与之合作，以使其设置正确。
具有讽刺意味的是，在 100% 的情况下，我们将生产从虚拟化中移回专用硬件，性能在专用硬件上达到了顶峰。在所有这些情况下，它不是虚拟化，而是它的设置方式。通过回到专用硬件，我们实际上证明了虚拟化可以更好地利用资源 5 倍或更多。现代软件通常设计为跨节点横向扩展，因此虚拟化在这方面也对您有利。
虚拟化软件时，我最关心的通常是许可。
这是一篇关于 MS SQL 的文章。不确定您的情况，因此无法挑选出任何重点。
SQL Server 在虚拟环境中受支持。事实上，我会建议它看到许可选项之一是每个插槽。这意味着您可以在虚拟化（例如 Windows 2008 Server Datacenter）系统中放置任意数量的 SQL Server 实例，并且只需为机器拥有的每个处理器插槽付费。
它比这更好，因为 DataCenter 是按插槽许可的，并且还具有无限的虚拟机许可。
不过，我建议将 Hyper-V 集群在两台机器上，这样如果一台机器出现故障，另一台机器就可以弥补不足。
我认为数据发生不良事件的可能性太大了。
作为一个简单的例子，假设您在 Virtual Server 2005 R2 中运行了一个 SQL Server 机器并打开了撤消磁盘（因此，主“磁盘”文件保持不变，并且所有更改都对可以清除的单独文件进行或稍后合并）。然后发生了一些事情（通常，您遇到了 128GB 的限制或任何大小），并且一些无知的管理员必须在半夜重新启动并发现他无法这样做，直到他删除了撤消磁盘。你搞砸了——即使他保留撤消磁盘文件以供以后分析，将数据合并在一起的可能性也很小。
因此，与此线程中的其他帖子相呼应-对于开发来说这很好，但对于生产来说这不是一个好主意。您的代码可以重建和重新部署（这是另一回事，用于源代码控制的 VM 也不是一个好主意），但您的实时生产数据更为重要。
还应考虑在处理 Vitalization 时可能引入的安全问题。虚拟化安全是 PandaLabs 的一篇很好的文章，涵盖了一些问题。
你从错误的角度看待这个问题。首先，您不会从供应商那里找到为什么您应该“不”虚拟化或为什么应该虚拟化的白皮书。
每个环境都是不同的，您需要做在您的环境中有效的事情。话虽如此，有些服务器非常适合虚拟化，有些则不应该虚拟化。例如，如果您的 SQL Server/s 每秒执行数百万次事务，例如，如果您的服务器位于纽约证券交易所或纳斯达克，并且数百万美元依赖于它，那么您可能不应该对其进行虚拟化。确保您了解虚拟化 SQL 服务器的后果。
我已经看到人们一遍又一遍地虚拟化 SQL 只是因为虚拟化很酷。然后稍后在 VM 服务器未按预期执行时抱怨。
您需要做的是设置一个基准，全面测试您想要部署的解决方案并展示它可以做什么和不能做什么，这样您就不会遇到任何意外。虚拟化很棒，它有利于环境并通过整合节省成本，但是您需要向您的主管说明为什么您不应该虚拟化您的 SQL Server，并且只有您才能做到这一点。