In my performance and capacity planning discussions, I talk about the proper order of server virtualization within SharePoint. For example, it might make sense to virtualize your web servers and query servers first as these roles typically require less hardware resources and scale out well across multiple VM's with little configuration effort. Next, for those using MOSS enterprise, the Excel role might be a candidate for virtualization. Typically, Excel is thought of as a resource hog and I would say that's true when used for heavy calculation and rendering, but I think for most enterprises, Excel is not yet being leveraged heavily. Additionally, Excel is scale out friendly as it requires little configuration to leverage multiple VM's. These factors make Excel a good candidate for virtualization.
The next candidate for virtualization is the Index server. First of all, if you don't use MOSS search or only index less than say, 1 million items or 500GB of content, feel free to virtualize the index server. However, if you index more content or expect to grow your indexing needs significantly, I would highly caution against virtualization. There are two main reasons for that: 1. Indexing can and does use significant processor and IO, perhaps more than can be allocated in a single VM, and 2. The index server role cannot be scaled out like other roles. Yes, you can have multiple index servers in a farm, but those indexers are bound to separate Shared Service Providers (SSP's) which limits the usefulness of scaling out. If your virtualization platform supports granting unlimited hardware resources (Hyper-V is not such an animal) and you trust it (I wouldn't) then perhaps you can virtualize your index server. Keep in mind, that the index server may require an entire servers worth of hardware or more. I suspect for the majority of shops, the index server should remain on large robust physical hardware. At a minimum, 8 processor cores, 16GB of RAM, and 8 fast disks @ Raid 10 dedicated to indexing. If you have a set server SKU for VM hosting, make sure it's large enough to support your index server and can be dedicated to that single index server VM. Otherwise, make sure your virtualization platform can support seamless migration to another host (most do) so the index server VM can be moved to larger hardware when needed. (it's not possible to maintain search available and change index servers )
Finally, there's the SQL role. Unlike the other roles in the SharePoint topology, best practice suggests that this role always be dedicated. That means you should not combine this role with any other SharePoint roles mainly because SQL is the lifeblood of a healthy SharePoint farm on which all other farm components depend. Proper SQL performance requires careful and diligent planning and maintenance and that's hard to do when the SQL server is also running web and application components. To that same end, SQL should be the last server to consider virtualizing. Virtualization at its core is all about sharing and you can think of SQL as that greedy little kid in grade school who never shared his cookies with you. SQL will and should take over all the hardware you throw at it. A properly designed SQL server could very likely have 8 cores (preferably 16), 32GB of RAM (64GB preferred) and a whole lot of disks (100+) with multiple controllers for redundancy and performance. It would be very difficult to virtualize such a beast and not suffer performance problems. Additionally, the scale out approach for SQL with SharePoint is not perfect. While you could very easily run 2, 3, 20 or more SQL servers in a single SharePoint farm, load balancing across those SQL servers is not seamless. You will always have a single SQL server hosting your configuration database and for simplicity's sake, it would be best to host all your administrative databases together as well. While it's entirely possible to provision content databases across multiple SQL servers and load balance site collection creation across those servers, it requires careful forethought and planning and still doesn't protect you from performance issues within specific databases. With all this in mind, SQL virtualization makes less sense and those considering SQL virtualization should plan to do so carefully. (cowboy administrator's need not apply)
Finally, if this wasn't enough detail for you (it shouldn't be), there is a wealth of knowledge being accumulated on the interwebs. I will point you to Brent Ozar's blog. Brent is a SQL guru extraordinaire and a colleague of mine at Quest Software. He has written two great posts on virtualization and SQL. The first, talks about the compelling reasons for virtualization. The second, talks about why virtualization and SQL don't mix.
Here are some other resources on virtualization:
Support statement: http://support.microsoft.com/default.aspx/kb/909840
Microsoft Whitepaper on SharePoint virtualization: http://download.microsoft.com/download/1/6/f/16f53b33-a118-4d78-a3d8-653a139aec0e/Virtualization_of_SharePoint_Products_and_Technologies_White_Paper_-_final1%20(2).pdf
Discussion on SharePoint and virtualization: http://blogs.technet.com/matthewms/archive/2009/02/06/technet-radio-interview-sharepoint-virtualization.aspx
Virtualizing SharePoint series:http://blogs.msdn.com/uksharepoint