InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comThu, 23 May 2013 10:13:26 GMT20http://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxIf you want to see how a site delivering over 2 million page hits per day running on Amazon Web Services (AWS) performs, then look at [url]http://www.totaljobs.com[/url]We completed our migration to AWS, using SQL 2012 running on Windows 2008 R2, in November 2012, and want to give a presentation about how we did this at SQLBits XI in May 2013. If you want to see this, please vote for [url]http://www.sqlbits.com/Sessions/Event11/AWSome-Totaljobs_moves_to_the_cloud4[/url]Mon, 17 Dec 2012 05:13:46 GMTEdVassiehttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxI'm not sure that I agree that is "all you need to do", but true since this thread has started VMWare has improved considerably and it can be used for production environments. There are several things that are key, like Remote Drive Management instead of using the VW File System, and making sure that you protect your VM from having it's memory stolen by the balloon driver, and there are several way to do that. Regardless, performance is harder to manage on a virtualized system and you have to be careful to protect you database VMs from being abused by other non-SQL Server VMs. Given enough excess capacity you can have "stellar" performance even without doing these things, albeit at a much higher cost in hardware than you would have otherwise had to pay. In that case I think I would say that you are getting performance "in spite of Virtualizing" instead of because of it. Hey, if money is no object you can do almost anything right?Tue, 11 Dec 2012 07:38:13 GMTDonald.F.Denneyhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxHow you configure your virtual enviornment is vital to using it for SQL Server. All of our servers are virtual including our production servers and our performance is stellar. Our biggest database is over 2 tb and we do not have any problems with performance. There are a few basic settings with the drives formatting which will need to be used instead of the default and you are good to go.Mon, 10 Dec 2012 08:23:40 GMTJules Bui-131038http://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxWe configured a high transaction database server with large throughput and found that the system IO was 18 - 30% slower according to our IOPS meter in Virtual machine than a similarly configured physical machine. We could buy some with attached storage but not enough to make it pay. It will get there some day, and some databases virtualize okay but not high transactional ones.Mon, 19 Sep 2011 15:40:44 GMTDavid Fulton-388478http://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxDepending on the IOPS requirements of your SQL Server, you may need to use pass through I/O. By default, all VMs in an environment are assigned storage from the "shared pool". This can greatly complicate I/O performance management, if it is important. For Dev and even possibly QA it may not be as important. However, for Production and in some cases even QA I/O performance is very important. In that case LUNS can be created external to the VM pool the same way they would be for a physical box, and then presented to the VM as though it were a physical box. This allows you identical storage peformance and tuning as though you were using a physical box.Tue, 06 Sep 2011 09:58:25 GMTDonald.F.Denneyhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxIf I'm using Hyper-V is the maximum number of virtual CPUs 4 per VM ?(my SQL instance on physical server currently utilizes 16 cores)Tue, 06 Sep 2011 09:41:16 GMTKK-291001http://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxI would have to say also it depends. It depends on the VM solution and the team that designs and deploys it.I have seen several VM solutions that operated faster than the systems they replaced and had better utilization of more resources. Recently this has been greatly improved.I have seen other solutions, all of these used free VMware or VirtualPC, that were so slow and unreliable they never were used.Tue, 21 Jun 2011 15:00:25 GMTSanDroidhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxWe are currently utilizing VMWare on our development and test environments only. Due to hard drive constraints, we tend to have to plan large data imports on the development side on specific databases at a time. The discussion has been brought up many times about moving away from VMWare on all of our SQL platforms to mimic the production side more closely.Wed, 03 Nov 2010 09:23:05 GMTMeet George Jetsonhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxI cannot find the ref right now, but if I'm correct you should be able to - and [b]must [/b]- take control over IO.This is the critical point that makes people use Hyper-V with SQLServer.[url]http://msdn.microsoft.com/en-us/library/cc768529%28BTS.10%29.aspx[/url]contains a section "Optimize Performance of Disk, Memory, Network, and Processor in a Hyper-V Environment"Measuring is documented at [url]http://technet.microsoft.com/en-us/library/cc768535%28BTS.10%29.aspx[/url]These are not the refs I was looking for, but they handle VM and IO:[url]http://download.microsoft.com/download/d/9/4/d948f981-926e-40fa-a026-5bfcf076d9b9/SQL2008inHyperV2008.docx[/url][url]https://globalsp.ts.fujitsu.com/dmsp/docs/wp-pr-hyper-v-en.pdf[/url][url]http://www.virtualpro.co.uk/2010/05/10/storage-io-control-sioc-vmware-drs-for-storage/[/url]Wed, 03 Nov 2010 08:34:05 GMTALZDBAhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxWe are considering sql server virtualization and the major question I have is resource contention. If I have four virtual servers running then the all have to share resources and I would think that contention could be an issue. i'm thinking we should just go with multiple instances rather than having virtual servers running sql server.Wed, 03 Nov 2010 07:45:02 GMTericwenger1http://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxSeems to me if you only have one instance of EE on your virtual host, you would only need to license the [u]virtual procs assigned to that SQL instance[/u]. [url=http://www.microsoft.com/sqlserver/2008/en/us/pricing.aspx][/url]Mon, 11 Oct 2010 11:40:24 GMTSequelDBAhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxPersonally, I prefer not to run critical apps on virtuals. Past experience, shared resources, etc. I also prefer SQL Server instances to running a mass of virtual SQL servers. One thing to keep in with VMWare and virtual SQL servers, especially the PROD ones, is licensing. My previous place got a rather hefty and unexpected true-up bill from Microsoft. We got heavily billed for Enterprise Edition. And heres why... basically we had Enterprise Edition installed on one of our reporting servers (load balanced front-end, single DB) and basically got billed for an enterprise license for every CPU on the virtual host. WTF?!?!? Got a very basic explanation and it was along the lines of the virtual host does the sharing of resources...Looking for more info now.I may be wrong... [url=http://www.dabcc.com/article.aspx?id=1546][/url]Fri, 08 Oct 2010 06:20:46 GMTgrahamchttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxRackspace has moved their headquarters from a building once occupied by Datapoint Corporation to the unoccupied Windsor Park Mall in Windcrest, Texas. Rackspace's Chairman, Graham Weston, owned the Montgomery Ward building in the mall until 2006, when it was sold to a developer. [URL=http://www.managed.com/]Managed Hosting[/URL]Fri, 08 Oct 2010 05:28:22 GMTmanueljordan96http://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxIf you are moving machines make sure to also plan out carefully where the database files will be. Separation between the OS, data and log files as well as tempdb can be very important.Fri, 09 Jul 2010 13:56:42 GMTJoie Andrewhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxHi,thanks for all your replies, some really good ideas here. I think the main issue with the dog slowness of the box is because of the Virtual server AND a heavily fragmented database AND this db has many tables with over 100,000,000 rows in them. Trying to rebuild indexes was taking forever!Edit: forgot to add, the drives where the datbase files live was massively fragmented also, however because the files were large, a defrag of the drive didn't help much.In the end we have decided to move a better hyper-v server with SQL 2005 Developer (this is only a test box) x64 and use partitioning.However if I had to carry on using this box I would have started on the index fragmentation probaby one table at a time, as I can estimate that some clustered index rebuilds would take an entire weekend. :w00t:thanks again[i][b]qh[/b][/i]Fri, 09 Jul 2010 02:56:58 GMTquackhandle1975http://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxWell I would definitely say that your indexes should be rebuilt if any of them have large fragmentation. Does the server have any maintenance periods, non-business hours or known periods of low activity? I would think that those time slots would be prime candidates for getting some of your index maintenance tasks done. Since you have stated that you are supporitng a VLDB, I would look to work on the most fragmented indexes first. You may not be able to rebuild/reorg them all within a single period, but given enough regular maintenance periods you should be able to get through them all.How often are you performing full backups? Can some of that time be alloted for rebuilding indexes?Thu, 08 Jul 2010 14:19:16 GMTJoie Andrewhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxThere are quite a few other (non work intensive I've been told) Virtual servers (also they aren't using VMWare but Virtual Iron) on that server also. Found out last night that the drive where my VLDB resides is massively fragmented, ran the defrag, nothing changed.I know the database indexes are fragmented but it seems like the chicken and the egg, need to rebuild indexes to speed up performance but even trying to do this is taking too long.Back to the drawing board. :ermm:[i][b]qh[/b][/i]Thu, 08 Jul 2010 02:13:23 GMTquackhandle1975http://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxHow many VMs are running along with the SQL VM on the same physical box, and what kind of servers are they?Wed, 07 Jul 2010 18:29:20 GMTJoie Andrewhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxDid you run column statistics? Also, don't forget to check the index, table, and file fragmentation. Diskkeeper or another third party tool is good to defragment database files on disk. Often, you can defragment with the database open and online. Don't forget to fine-grain stripe tempdb. Sometimes, you can mitigate poor performance by larger amounts of RAM, using stored procs, and having a faster disk subsystem. Look at the NIC cards. Be sure to have dual pathing in place and use fiber not iSCSI. Check the RAM cache on the controller card.DocWed, 07 Jul 2010 07:20:21 GMTdoc_sewellhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxI have a VMWare SQL 2000 Standard SP4 on Windows 2003 Server SP2 test box and I am looking for ways to speed it up. It has 4 cpu's and 4GB RAM. Granted it's only test however I have recently moved a 480GB database on it and I am performing some intensive queries and need to check the index fragmentation and possibly rebuild them, plus backup and restore VLDB's.What steps can I take to speed this instance up - or is it just the nature of the beast ie - VMWare?would 'Boost SQL priorty on Windows' help any?Many thanks[i][b]qh[/b][/i]Wed, 07 Jul 2010 05:41:11 GMTquackhandle1975http://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxThanks for the link, Joie. I think that's a relatively recent change on MS's part to support VMWare, and I'm glad to see it.Wed, 28 Apr 2010 17:00:25 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxI have to disagree with Joe. While I am not the biggest supporter of VMs on SQL (especially the potential nightmare live migrations can have on a very active server), Microsoft does in fact support VMWare on certain setups. VMWare is a partner in their Server Virtualization Validation Program (SVVP) which Microsoft supports officially under approved setups.[url=http://support.microsoft.com/kb/957006/]Microsoft server software and supported virtualization environments[/url][url=http://www.windowsservercatalog.com/svvp.aspx]Welcome to the Windows Server Virtualization Validation Program[/url]Wed, 28 Apr 2010 16:30:02 GMTJoie Andrewhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxHmmmmm......I am going to have to respectfully disagree with Doc-s. We started down the VMwarepath 15 months ago and have not looked back. Going VM allowed us to consolidate the rack space for approx 35-40 hardware servers into about 22U in one rack. We run 4 ESX servers with full redundancy ( if my terminology is bad, is because I'm the DBA, not the VM guy...), fail over, auto-switching to a new ESX box, etc. All the advantages of VM in an environment not from MS. We now have at least 40 servers on the VM environment and as hardware servers get to EOL warranty-wise, the databases are being migrated to VM. Supported or not, VMware has served us well, especially in a production environment. The savings in hardware costs and environmental expense is not my responsibility, but just getting rid of 40 4U/6U servers has to be a savings of some magnitude. Talk about ease of maintaining the databases. In this day of personnel and budget cutbacks, VM can not be beat. We have even managed to free up rack space for the GeoData group to move back into the main computer room, which will allow that department to vacate an expensive rental site - more cost savings. Can't be beat.Wed, 28 Apr 2010 14:57:29 GMTnelsonj-902869http://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxThat is true, but it's never been my decision. Which Virtual platform to use, i.e. Microsoft or VMWare, supported or not, has always been the pervue of the Windows Administration team. Even though they know it isn't fully supported by Microsoft management has always decided to take that risk. I neither condone or advise against it, since it's not my call. I imagine that many other DBA's find themselves in a similar situation.Wed, 28 Apr 2010 14:45:13 GMTDonald Denneyhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxAnother point to remember, Microsoft does not support VMWare. You must consider Hyper-V. Again, when your job counts on it, not for production.JoeWed, 28 Apr 2010 14:17:26 GMTdoc_sewellhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxRunning a Production SQL Server that is highly transactional is an extreme issue. We have had customers with tempdb problems, poor or no response, and database corruption (CHECKDB errors). Can you run SQL on a VM? Yes. But, as a DBA, I would only run dev or test, [i]never[/i] production.Wed, 28 Apr 2010 14:15:12 GMTdoc_sewellhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxGary, I'm not necessarily disagreeing, but stating that as a DBA, I don't like to put enterprise level tuning of OLTP and OLAP SQL servers in the hands of non-DBAs. I think all technologies can be "tuned" to their maximum potential, my point is that in practice, that requires a level of expertise and integration between server and DBA personnel that most organizations don't really have.For example, given an equal choice between a midlevel server, one could VM it or multi-instance it - give the same resources to each. Implement database mirroring as a hot failover solution, get the benefits of transactional integrity compared to hardware level solutions that may not respect transactions. You could cluster either scenario. The performance requirement is that a failover must perform equally to the primary server. I wouldn't want either the VM or multi-instanced machine to share with non-SQL servers. Given that, the additional overhead of VM would theoretically reduce the maximum potential of the machine. With hot swap memory, disks or hba (depending on which you are using), the same machine can expand without downtime.You are correct that data centers have too many under-utilized machines, and if the DBAs are not using resources well, that is a good motivation to consolidate using VM. The right tool for the right job most certainly applies to which strategy works best for a company, as does understanding whether the infrastructure or DBA personnel are in the best position to maximize resource use of the database servers.Still, for performance/DR/failover scenarios running SQL2008 EE in heavy OLTP and OLAP, I don't think even the best tuned VM can deliver performance at a lower cost than the best tuned physical, multi-instanced machines. I'd love to be wrong, as I can see the potential for multi-instancing on VMs if the numbers add up!!Thu, 11 Feb 2010 09:40:35 GMTpaul.aasmundstadhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxI'm not sure that I think multi-instancing is better than VMs. First you can't balance memory easily with instances. VMs allow you to more easily move memory around. That may or may not fit.In terms of licensing, I'm not sure that's true either. Depending on your version, there may be no difference between licensing 4 instances and 4 VMs. The licensing has changed by edition, version (SS2K v SS2K5 v SS2K8), and type of licensing. You'll have to check for your situation if this matters. In terms of running stable environments, one of the large satellite TV providers runs almost all VMs for their servers. A couple of the very heavily used SQL Servers are not on VMs, but dozens of their SQL installations are, including many fairly important databases. They do use a couple of tricks to make the database servers work differently than things like DCs, file servers, etc. Normal servers are usually 10:1 on a blade. SQL Servers are about 4:1. They also have virtually clustered the SQL Servers and do not allow them to flow with Vmotion. A few float, but many do not, and with dedicated HBAs, this allows failover to another blade with known performance characteristics.I am also not sure I agree that VMs are there to sell SAN space. A SAN may or may not be a good idea in your environment. I'm torn on them as performance can be better or worse, administration costs are higher, new machines, etc. On the other hand they do centralize storage, allow some interesting DR options with 2 SANs and they can have great performance. You can also more easily grow space, or add space, to a server than with DASD. VMs don't require SANs; you just need to set up good IO subsystems however you run things. The SAN is there if you want to float those VMs to new machines and require shared disk.I've seen VMs also cause performance problems because sysadmins think that a new VM somehow gets them free resources. You still need to balance and plan for performance. They do allow you to quickly increase hardware if demand changes. If your 2x2 or 2x4 suddenly is too small and you need a 4x8, VMs are a great way to do this. Previously people caught in this situation tended to overbuy machines to prevent it since it is much harder in many companies to get the approvals to upgrade a machine, or buy a new one. As a result we have many under-utilized machines in data centers that also cover up planning mistakes.Thu, 11 Feb 2010 09:10:26 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspx[quote][b]Donald Denney (2/9/2010)[/b][hr]Here is the information about the paper:Consolidation Using SQL Server 2008SQL Server Technical Article[/quote]URL for the paper: [url]http://msdn.microsoft.com/en-us/library/ee692366.aspx[/url]Thu, 11 Feb 2010 08:58:31 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxMulti-instancing is IMHO a superior approach. You get hardware and licensing consolidation, streamlined patch/sp processes, a true picture of hardware level metrics, and a better optimization routine for parallel or heavy loads. Unless you NEED distinct operating environments, there is no reason to pursue VM vs. multi-instancing. Since we don't like to share IO or other resources with other kinds of servers, are mindful of HBA limits, and want "true" resource pictures for performance tuning and capacity planning, we'd prefer to not to go down that route. Ideas of using host migration for SQL servers to me is not good - if you are improperly balanced at the ESX level, this technology covers up your more fundamental design problem. Sometimes SQL servers will have heavy load (indexing, jobs, etc) - I don't want that to overload my host, and if I do, I want more resources permanently, not temporarily by moving the server. Otherwise you end up with round robin server migrations instead of solving the problem.VM is a great way to sell SAN storage, save rack space, get more utilization out of unver-used resources, and cover up capacity/performance planning mistakes. None of which have anything to do with what I am concerned with as a DBA. However, I think you'll find multi-instancing meets the consolidation and cost saving goals of VM, but in a way that keeps performance, manageability, and responsibility in the hands of the DBA.Thu, 11 Feb 2010 08:17:55 GMTpaul.aasmundstadhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxWe have about 50 SQL Servers on VMs, mostly production, but some are development. We do not generally put highly loaded servers on VMs, but they are great for "one off" special purpose servers.I would say that as long as the VM environment is well managed, that there is no problem. In general, our VM servers have no more downtime than "real" servers.It saves a lot of management effort and money to be able to do physical to virtual migrations for older servers, rather than keeping them on hardware maintenance contracts or replacing them with new hardware. Being able to move from older, failing hardware without having to reinstall OS, SQL,and application software is a huge time saver, especially when it is older software that is not well supported.Wed, 10 Feb 2010 15:31:20 GMTMichael Valentine Joneshttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxI'm not a Windows Administrator, so I don't know all of the details or pitfalls related to making VM stable. I do know that we have very little problem with our Virtual Machines staying up or being stable. Partly that might have to do with a product called "VMotion", which not only can be used to migrate Virtual Machines to other Physical "ESX" frames, but will automatically fail those machine over to other frames in the result of failure. I've seen where an ESX frame went down, and the Virtual Machines on there migrated to several other frames, with VMotion deciding where they should go based on resource availability and resource needs, and the people using the Virtual Machines had no idea they had even migrated. There is some performance degradation while this happens, but it's much more seamless that failover within a Microsoft Cluster. Not only does the database instance not shutdown, but the windows OS never "shuts down". It's pretty impressive. I do have misgivings about he ability of the VM environment to provide truly reliable, consistent resources without adversely impacting performance. For that reason, I too am leery of putting anything too mission critical or performance sensitive on them, especially something that is truly resource intensive. I started out being a pretty big VM sceptic myself to be honest, but over time I've been shown that a lot of my original fears unfounded.Wed, 10 Feb 2010 15:21:05 GMTDonald Denneyhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxI agree with Donald Denney on this. I went to an England PASS meeting on this two years ago, and the answer was "it depends". The biggest issue with virtualization tends to be capacity planning. If the physical box is configured correctly and the SQL server being virtualized does not have demands that will bring other VMs on the box down, then I believe it can be done safely. Not only that, but for things like SSRS and configuration databases that do not change much, it is probably a good solution for them.On the other side of the coin though, I do not think that mission critical databases should go on them. There is a lot that I have read about the features of virtualization, but a lot of it has been stated without real-world data, so that leads me to believe they are selling proof-in-concept solutions, which I do not want to risk with my critical data. Also, some features such as virtualization snapshots are not supported by Microsoft under any vendor, including MS. I also do not think that it would be able to handle a replicated environment well either.The choice is yours, but I tend to think of mission critical heavy OLTP instances as the last ones to be virtualized, if at all.Wed, 10 Feb 2010 14:56:43 GMTJoie Andrewhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxI agree with Linda, we have SQL instances on Virtuals in Test Environment for more than two years. We had problems with Virtuals Host failing which brings down all viruals hosted on that server. I wouldn't recommend using Virtuals in Production environment, no chance.Wed, 10 Feb 2010 09:39:37 GMTGTRhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxWe have about half of our production SQL servers on VMWare. For the most part these are systems that are not highly transactional. I've really had no issues with them over the past couple of years. In the beginning we did have to be careful about which applications shared the same VM host. Things also got better when we began to use SAN as the disk storage medium.One really nice plus is the ability to clone the VM to create a Dev or Test environment.Wed, 10 Feb 2010 09:29:51 GMTEd Zannhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxThat's a bit of a generalization, and not really accurate anymore. Virtualization has improved considerably recently, and many production databases perform quite well on a virtual machine. So the answer is really, it depends on the production database. What are it's requirements for I/O throughput, CPU usage, etc. There are some advantages to using Virtualizaton and also some disadvantages. If you use pass through storage with a dedicated HBA, the only real tricky part that I have found is the allocation of CPU resources. That's the one part of VMWare that still in my opinion still has some issues that can make performance tuning tricky. There is a very useful white paper on SQL Server Consolidation, and this includes using Virtualization to consolidate. Here is the information about the paper:Consolidation Using SQL Server 2008SQL Server Technical ArticleWriter: Allan Hirt, Megahirtz LLC (allan@sqlha.com)Technical Reviewers: Lindsey Allen, Madhan Arumugam, Ben DeBow, Sung Hsueh, Rebecca Laszlo, Claude Lorenson, Prem Mehra, Mark Pohto, Sambit Samal, and Buck WoodyTue, 09 Feb 2010 14:59:18 GMTDonald Denneyhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxI don't recommend a VMWare instance for a production SQL Server. A virtual machine only gets a portion of disk space, memory, and CPU so performance isn't very good. We had a SQL Server test environment set up and performance was such an issue that it is no longer used. I think virtual instances might be ok for testing functionality only, but I would never use it in production.Tue, 27 Nov 2007 13:20:19 GMTLinda Johanninghttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxI haven't seen any, but I'm looking for some.There is one from VMWare, but since they're selling virtual software, not sure how much to trust it:http://www.vmware.com/files/pdf/SQLServerWorkloads.pdfMon, 26 Nov 2007 10:56:12 GMTSteve Jones - SSC Editorhttp://www.sqlservercentral.com/Forums/Topic422058-5-1.aspxHi,I'm collecting information, recommendations about advantages and disadvantages of usage a virtual server for a [b] SQL Server in production[/b] environment.Do you any test results or benchmarks regarding performance, security, availability and so on?ThanksWed, 14 Nov 2007 06:06:53 GMTMajid-454469