我可以根据个人经验这么说，因为我正在处理这个问题.我目前作为承包商工作的地方为他们的 SQL Server 开发系统提供了这种类型的环境.我正在尝试开发一个相当温和的 B.I.系统在这种环境下，并且真的在努力解决性能问题.

TLB 未命中和模拟 I/O 在纯虚拟机上非常慢.如果您的 O/S 具有半虚拟化支持(这在 Windows 上仍然不是成熟的技术)，则您使用半虚拟化 I/O(本质上是挂接到 VM 中的 API 的设备驱动程序).Opteron 的最新版本支持嵌套页表，无需在软件中模拟 MMU(这真的很慢).

因此，在大型数据集上运行并执行大量 I/O(例如 ETL 流程)的应用程序会遇到虚拟化的致命弱点.如果您有诸如数据仓库系统之类的可能对内存或磁盘 I/O 有困难的东西，您应该考虑其他东西.对于简单的事务性应用程序，它们可能没问题

透视我正在使用的系统在具有 4x 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 开发人员版附带 V.S.专业版及以上.

这也有一个好处，即您的开发团队从一开始就***处理部署 - 您必须提出一个易于一键式"部署的架构.这并不像听起来那么难.Redgate SQL Compare Pro 是您的朋友.您的开发人员还可以获得数据库管理的基本工作知识.

快速访问 HP 网站为我提供了一个 XW8600(他们当前基于 Xeon 的型号)的标价约为 4,600 美元，带有四核 Xeon 芯片、4GB RAM1x146 和 4x73GB 15k SAS 硬盘.街价可能会低一些.将此与 SAN、刀片机箱和 VMware 许可的价格以及该设置的备份成本进行比较.对于备份，您可以提供带有备份的网络共享，人们可以根据需要删除压缩的 DB 备份文件.

AMD 网站上的这份白皮书 讨论了 VM 上的一些基准测试.从后面的基准测试来看，繁重的 I/O 和 MMU 工作负载确实削弱了 VM 的性能.他们的基准测试(由于它是供应商提供的统计数据，所以有点保留意见)表明 OLTP 基准测试的速度会降低 3.5 倍.虽然这是供应商提供的，但应牢记:

• 它对原始虚拟化进行了基准测试并将其与半虚拟化解决方案，而不是裸机性能.

• OLTP 基准测试将具有更多随机访问 I/O 工作负载，并将花更多时间等待磁盘寻求.更连续的磁盘访问模式(特征数据仓库查询)将有一个更高的惩罚，以及大量内存操作(例如，SSAS 是一个圣经记忆猪)有一个大量的 TLB 未命中也将承担额外的罚款.这意味着这方面的放缓处理类型可能是比 OLTP 更明显白皮书中引用的基准惩罚.

我们在这里看到的是，TLB 未命中和 I/O 在 VM 上非常昂贵.在 MMU 中具有半虚拟化驱动程序和硬件支持的良好架构将缓解部分或全部问题.但是，我相信 Windows Server 2003 根本不支持半虚拟化，而且我不确定 Windows 2008 服务器中提供的支持级别.根据我的经验，与规格相对适中的裸机硬件相比，VM 在处理 ETL 过程和 SSAS 多维数据集构建时会从根本上降低服务器的速度.

The IT department where I work is trying to move to 100% virtualized servers, with all the data stored on a SAN. They haven't done it yet, but the plan eventually calls for moving the existing physical SQL Server machines to virtual servers as well.

A few months ago I attended the Heroes Happen Here launch event, and in one of the SQL Server sessions the speaker mentioned in passing that this is not a good idea for production systems.

So I'm looking for a few things:

1. What are the specific reasons why this is or is not a good idea? I need references, or don't bother responding. I could come up with a vague "I/O bound" response on my own via google.
2. The HHH speaker recollection alone probably won't convince our IT department to change their minds. Can anyone point me directly to something more authoritative? And by "directly", I mean something more specific than just a vague Books OnLine comment. Please narrow it down a little.

I can say this from personal experience because I am dealing with this very problem as we speak. The place I am currently working as a contractor has this type of environment for their SQL Server development systems. I am trying to develop a fairly modest B.I. system on this environment and really struggling with the performance issues.

TLB misses and emulated I/O are very slow on a naive virtual machine. If your O/S has paravirtualisation support (which is still not a mature technology on Windows) you use paravirtualised I/O (essentially a device driver that hooks into an API in the VM). Recent versions of the Opteron have support for nested page tables, which removes the need to emulate the MMU in software (which is really slow).

Thus, applications that run over large data sets and do lots of I/O like (say) ETL processes trip over the achilles heel of virtualisation. If you have anything like a data warehouse system that might be hard on memory or Disk I/O you should consider something else. For a simple transactional application they are probably O.K.

Put in perspective the systems I am using are running on blades (an IBM server) on a SAN with 4x 2gbit F/C links. This is a mid-range SAN. The VM has 4GB of RAM IIRC and now two virtual CPUs. At its best (when the SAN is quiet) this is still only half of the speed of my XW9300, which has 5 SCSI disks (system, tempdb, logs, data, data) on 1 U320 bus and 4GB of RAM.

Your mileage may vary, but I'd recommend going with workstation systems like the one I described for developing anything I/O heavy in preference to virtual servers on a SAN. Unless your resource usage requirements are beyond this sort of kit (in which case they are well beyond a virtual server anyway) this is a much better solution. The hardware is not that expensive - certainly much cheaper than a SAN, blade chassis and VMWare licencing. SQL Server developer edition comes with V.S. Pro and above.

This also has the benefit that your development team is forced to deal with deployment right from the word go - you have to come up with an architecture that's easy to 'one-click' deploy. This is not as hard as it sounds. Redgate SQL Compare Pro is your friend here. Your developers also get a basic working knowledge of database administration.

A quick trip onto HP's website got me a list price of around $4,600 for an XW8600 (their current xeon-based model) with a quad-core xeon chip, 4GB of RAM and 1x146 and 4x73GB 15k SAS hard disks. Street price will probably be somewhat less. Compare this to the price for a SAN, blade chassis and VMware licensing and the cost of backup for that setup. For backup you can provide a network share with backup where people can drop compressed DB backup files as necessary.

EDIT: This whitepaper on AMD's web-site discusses some benchmarks on a VM. From the benchmarks in the back, heavy I/O and MMU workload really clobber VM performance. Their benchmark (to be taken with a grain of salt as it is a vendor supplied statistic) suggests a 3.5x speed penalty on an OLTP benchmark. While this is vendor supplied one should bear in mind:

• It benchmarks naive virtualisation and compares it to a para-virtualised solution, not bare-metal performance.

• An OLTP benchmark will have a more random-access I/O workload, and will spend more time waiting for disk seeks. A more sequential disk access pattern (characteristic of data warehouse queries) will have a higher penalty, and a memory-heavy operation (SSAS, for example, is a biblical memory hog) that has a large number of TLB misses will also incur additional penalties. This means that the slow-downs on this type of processing would probably be more pronounced than the OLTP benchmark penalty cited in the whitepaper.

What we have seen here is that TLB misses and I/O are very expensive on a VM. A good architecture with paravirtualised drivers and hardware support in the MMU will mitigate some or all of this. However, I believe that Windows Server 2003 does not support paravirtualisation at all, and I'm not sure what level of support is delivered in Windows 2008 server. It has certainly been my experience that a VM will radically slow down a server when working on an ETL process and SSAS cube builds compared to relatively modest spec bare-metal hardware.