Virtualizing SQL Server with VMware: Doing IT Right (VMware Press Technology)

This book is simply not factually correct on a large number of issues.Page 309 - the high availability chart shows pre-SQL-2012 clustering and SQL-2012+ clustering as having different recovery point objectives. (They don't - they just have different marketing names.) It says database mirroring, AlwaysOn Availability Groups, and failover clusters fail over in less than three seconds - that's just not realistic. It says you can do vMotion on a database mirror - that's not realistic either, because synchronous mirrors often fail over during long vMotions.Those errors are all on just one page, in one chart, and it just keeps coming.Page 111 says that if you put your log files on local SSDs, you should "have an additional copy on SAN." That's just not even physically possible with SQL Server - you can have two log files, but if either of them fails, your database is down. This concept is possible in Oracle, and the authors' Oracle background keeps showing up throughout the book. They recommend things that work in Oracle, but not in SQL Server.Page 111 also says that Microsoft recommends 1 data file per CPU core and .25 to 1 user database. That was true in 2005-2006, but Microsoft has since released multiple knowledge base articles like KB2154845 that have better guidance.I could go on and on (and in my book review on BrentOzar dot com, I do) but the bottom line is that you should wait for the next revision of this book. The first edition has too many technical problems.

Book was as expected with on time delivery.

This good goes into great depth about the entire virtualization stack as it pertains to Microsoft SQL server. It covers networking, storage, compute, and a whole host of SQL configuration options. While preparing for an upcoming SQL migration and remediation project I found the information extremely useful and relevant. It's a one stop shop for getting the low down on how to make SQL perform well in a VMware environment. If you want to ensure your SQL servers run optimally on VMware vSphere, then get this book and start reading.

Great insights and actionable steps though hope to have new edition with later vSphere software

It's a good book for who want migrate the SQL server to vSphere.

This book is chock-full of very detailed and useful information on virtualizing MS SQL databases. Some books and articles fall short by providing just enough information to get a DBA part way to a complete solution. This book goes extremely deep, with very specific configuration recommendations at every level of the infrastructure stack.One of the key items I like about a good technical book is the ability to use it not just for learning, but also as a quick reference. This book serves both purposes well.Overall, this is one of those must-have books in the technical library.

It’s not often that you’ll see me write a lengthy book review. Most book reviews are fluff telling you to buy or not to buy a book, but don’t contain a lot of the “why” or “why not” to do so. But, every once in a while a book comes along that just strikes him in all the right ways, especially if its topic is in a core focus of yours. The book “Virtualizing SQL Server with VMware: Doing IT Right” by VMware Press and authored by Michael Corey, Jeff Szastak, and Michael Webster, is a book that I feel every VMware administrator (and any other vendor’s hypervisor administrator as well) should purchase and read twice, and I’ll tell you why in this review.First and foremost, virtualizing business critical applications, in this case Microsoft SQL Server, is a challenge. The process is nowhere as easy as migrating a file server or preproduction sandbox. Processes and practices that may work well for some applications can cause serious heartburn, performance problems, and worse – instability – when virtualizing SQL Servers. VM administrators need to be aware of the differences, and this book delivers this knowledge and experience in droves.This book is targeted at VMware administrators and not SQL Server DBAs. Many technical references are made to infrastructure components that most DBAs have had no exposure to (and arguably should not have to worry about unless they are a nerd like me). However, DBAs should still read the book to get a small taste of what it takes to architect and manage the virtualized environment underneath their data. The knowledge of these layers is guaranteed to make them better DBAs, and will help both organizational silos speak the same language during architecture and triage situations.The author’s collective experience in managing these systems is quite apparent as you progress through the book. Many how-to’s and gotchya’s are described in detail. All are scenarios that I encounter frequently during my normal day in consulting around this topic. The advice presented is well thought out and shows the depth of the authors’ experience in the field.The best part of the book is that the authors spend a great deal of time educating VMware administrators on what SQL Server is and how it uses the infrastructure underneath it as it stores and retrieves data to fulfill its requests. The authors’ style is very casual and informative, and makes each concept and topic very easy to understand and digest. For example, DBAs understand SQL Server high availability and disaster recovery. So do VM administrators. But, the two strategies are usually very different, and one group does not know the capabilities of the other technologies and how they contrast or complement each other. When you put them together, what works for one might not work for the other, and the arguments generally ensue. The authors educate the VMware administrator on how SQL Server handles high availability and disaster recovery, and suggests VMware-based processes and practices that complement and improve what SQL Server handles well, all while leveraging the right technology for each layer of the stack.I feel that the real “meat” of the book comes in two sections – chapters five to nine and ten to eleven. The first group describes each layer of the virtualized infrastructure and breaks down architectural, performance, and configuration tips on why (and not just how) specific recommendations and architectural decisions are usually best for SQL Server on VMware.The last two chapters do a fantastic job describing the end-to-end baselining and benchmarking process that are so frequently absent in most environments, both physical and virtual. This process helps eliminate the “it’s slow” mentality that comes from subjectivity, and replaces it with a series of objective processes for putting performance metrics to each of these layers. These metrics are key for both helping to identify the root layer of performance issues if they arise, and also eliminates the finger pointing that accompanies the “it’s your fault until you can prove otherwise” attitudes that are found in any organization.No tech book is without its flaws, and a handful of items caught my attention while reading and re-reading this book.The authors make a claim that CPU and memory hot-add should be enabled. I personally feel that it’s not quite as black-and-white as this. Hot-add of resources in a guest is a great feature, but hot-add also disabled virtual NUMA presentation to the VM. Correctly-sized virtual NUMA and SQL Server can improve performance, and hot-add of resources expressly disables virtual NUMA. I’ve implemented both, based on need, and I would like to see a broader discussion on the pros and cons of this setting.Next comes the recommendation for one dedicated physical CPU core for each virtual CPU core. In my experience, it’s a great place to start, but it’s almost always too conservative and ends up “wasting” CPU time that you pay for in the form of SQL Server core-based licensing. I’d like to see this conversation include a discussion of using CPU Ready and Co-Stop times as a more objective metric for CPU overcommitment.The jump straight into the discussion around hyper-converged architectures, in this case Nutanix, felt abrupt. Preceding this chapter should have been a short chapter comparing and contrasting the differences between rack servers, blade servers, and hyper-converged architectures. A solid discussion of how SQL Server is architected differently on each of these platforms, and the implications on performance, availability, and scalability would be a welcomed segue into the discussion on the emerging field of hyper-converged environments.As with any first edition book, a handful of technical inaccuracies and academic practices are present, but I feel that none detract from the true mission of the book – to educate VMware administrators on virtualizing SQL Server. Items such as references for a SQL Server data file per vCPU core or data file placement sound good in theory but in practice can be tough to manage as an environment scales. I feel confident that the authors will correct the items that have been pointed out by myself and others in the next version of the book.Some of the new features included in the recent launch of vSphere 6.0, well after the release of this book, changes some of the recommendations made in the book. I know that this release will contribute to some changes in the next version of the book as well.To summarize, I recommend this book without hesitation to any VMware administrator who has, or needs to, virtualized business critical applications – and not just SQL Server. I give it 4.5 out of 5 stars, and look forward to seeing more from these authors in the future!

This book is fine for VMWare (and other virtualization) admins to prepare for virtualizing small, non-critical DBs. It unfortunately makes mistakes on the technical details of how SQL Server works, and the recomendations for sizing are simply inappropriate/wrong for a medium-large sized SQL instance (especially the memory sizings). I am afraid that managers (or worse junior technical people) are going to get their hands on this book and use the recomendations to set policy and/or provision machines. If you're putting the SQL backend for an app with 15 users this will be ok, but I wouldnt let anything along these guidelines host even the dev environment for any of the apps that I support (400+ apps on 75 bare-metal servers; 2k8-2012; 1.2TB/hr avg data throughput per server; international bank).I would have reviewed higher if the book had specified that it is for small, commodity DBs, but as it touts its recommendations for "enterprise" instances, I cannot recommend it. Sorry.

Worth every penny