I spend a lot of time talking to organizations and helping them virtualize their mission critical applications.  In the last few years, many organizations have had success virtualizing Exchange 2010.  A big reason why is due to the architectural changes in Exchange that have reduced I/O requirements as well as introduced new availability features.  Combine that with the fact that Microsoft has relaxed their support policies around virtualizing Exchange and it is no surprise that many organizations have chosen to virtualize 100% of their Exchange 2010 environment.

I think that it is now Microsoft SQL that will be the next big mission critical applications that organizations will choose to virtualize.  I’ve already spoken with many large organizations myself this year alone who are interested in taking on large scale SQL virtualization and consolidation projects, and others which are looking to build SQL as a Service platforms as well.

Here are a few of the reasons why I think this is the year of SQL virtualization.

SQL 2012

With the release of SQL 2012, Microsoft has introduced new features that will make it much easier to virtualize SQL while still maintaining high availability.  Specifically, the new SQL 2012 AlwaysOn Availability Groups (AAGs) can provide nearly the same level of availability as a traditional SQL cluster without the strict requirements for virtualizing a traditional Windows Failover Cluster (MSCS).  AAGs can also have multiple passive copies (previously not possible with database mirroring), and the passive nodes can actually be used for read requests to offload processing from the active node.

So you get the availability of a cluster, along with multiple passive copies of the database, but you don’t have to go through the difficulties of virtualizing a cluster.  Despite the fact that Microsoft changed to a per-core licensing model for SQL 2012 I still see this as a big driver for organizations to move to virtualize their SQL 2012 environment.

Licensing

Even with the move to per-core licensing in SQL 2012, organizations can still save a lot of money by virtualizing SQL.  That is because when organizations move to the per-core model and license SQL 2012 Enterprise Edition, they can virtualize an unlimited number of SQL 2012 (or lower) instances on those cores.  I’ve personally worked with a number of organizations that either use the older Server+CAL licensing model or have a large number of CPU licenses that they can move into the virtual infrastructure and see significant savings.

There’s a lot more to the licensing story that I won’t get into here, but you can read my previous post on the subject.

Underutilized SQL servers

VMware has a large collection of data on production servers from its Capacity Planner data warehouse.  This data shows that the vast majority of SQL servers are actually very underutilized and require very little CPU, memory, or disk I/O.  Many people assume that SQL is difficult to virtualize because of the heavy performance requirements, but VMware’s data (in addition to my own observations at many customers) has shown that not to be the case.

Combine under-utilized SQL servers with advantageous licensing if you heavily consolidate your SQL workloads, and it is no surprise that many organizations are eager to virtualize SQL.  There may be heavy hitting SQL servers in your environment and those can be virtualized too, but it is likely that many of them are actually pretty light.

VMware is getting serious about mission critical apps

Earlier this year, VMware released a new competency for their partners called the Virtualizing Business Critical Applications (VBCA) competency.  VMware partners can go to Partner Central and receive free training and education to help them be successful with virtualizing business critical applications like SQL and Exchange.  If you work for a VMware partner and have not yet seen the training and information available for the VBCA competency, log on to Partner Central and go check it out (after you finish reading this post, of course).

VMware clearly sees the value in helping their partners be successful with virtualizing mission critical applications like SQL.  With VMware helping their partners to deliver successful projects, it can only help drive adoption of virtualized SQL (and Exchange, etc.) even higher.

In Conclusion…

Combine all of those things together with the scalability of vSphere 5, and you have a recipe for SQL virtualization.  Many organizations have already started down this path and others are just starting, and I believe that this year will be the year that more organizations choose to virtualize SQL than before.  And I believe it’s about time….

If you aren’t familiar with Jetstress, here’s a two second version:  Jetstress is a tool from Microsoft that simulates the disk activity of an Exchange Mailbox server.  It is used to simulate the load on the storage system used to host Exchange mailbox databases, and measures key attributes like disk I/O latency and total IOPS.

In my experience with Jetstress I’ve seen exactly what Microsoft has seen in the past.  Namely, results from Jetstress (particularly I/O latency numbers) that do not match what is reported by either the ESXi host or the storage itself.  So despite what Microsoft says here about the fact that Jetstress is now supported when run in a virtual machine, I still think it makes sense to independently validate the results.

As recently as last year I had a customer run Jetstress on their Exchange 2010 virtual machine that was running on vSphere 4.1 and the results were less than what we expected.  Once we ran it again and measured the I/O latency in both esxtop as well as from the storage array management software we could clearly see the numbers were within the acceptable range.

Why would the numbers be inaccurate?  Jetstress relies on in-guest timers to measure things like I/O latency, and so like any other in-guest timer they are susceptible to clock drift issues when the host’s CPUs become heavily loaded.  A more common tool for testing Exchange performance, Load Generator 2010, relies on a separate client machine and so the numbers produced from that are generally considered to be more accurate (though it doesn’t test the same thing as Jetstress).

I can see why Microsoft has made this change – combine the fact that you can easily get 10 core CPUs with hypervisors that have improved considerably over the years and you are unlikely to see many issues anymore.  For the most part you’re likely to see accurate test results unless the ESXi host itself is under heavy CPU contention.

Bottom line: I still recommend that results from Jetstress be validated outside the virtual machine using either esxtop or stats from the storage array, preferably both.  If all three match up then you can feel confident that the data you’re seeing from Jetstress is accurate.

The one support requirement that many folks aren’t aware of is the use of virtual machine snapshots on Microsoft applications, particularly Exchange or SQL.  For both applications, Microsoft is explicit in stating that virtual machine snapshots of any kind are not supported.

Why does this matter?  Many popular virtual machine backup products (purposely not naming any) rely on snapshots to take clean backups of running VMs.  That means using these products to backup Exchange or SQL VMs may be unsupported.

Here are the official Microsoft support statements for Exchange and SQL:

Microsoft Exchange 2010 System Requirements:

Some hypervisors include features for taking snapshots of virtual machines. Virtual machine snapshots capture the state of a virtual machine while it's running. This feature enables you to take multiple snapshots of a virtual machine and then revert the virtual machine to any of the previous states by applying a snapshot to the virtual machine. However, virtual machine snapshots aren't application aware, and using them can have unintended and unexpected consequences for a server application that maintains state data, such as Exchange. As a result, making virtual machine snapshots of an Exchange guest virtual machine isn't supported.

Support policy for SQL Server running in a hardware virtualization environment (covers all versions):

Virtualization Snapshots for Hyper-V or for any virtualization vendor are not supported to use with SQL Server in a virtual machine. It is possible that you may not encounter any problems when using snapshots and SQL Server, but Microsoft will not provide technical support to SQL Server customers for a virtual machine that was restored from a snapshot.

Pretty clear, right?  The SQL policy actually explains this the best.  They’re saying that you may not have any trouble using virtual machine snapshots, but if you restore a VM using a backup product that relies on snapshots then they will not support any issues with that restore.

What about virtual machine backup products that use an application aware VSS writer?  I’ve spoken to Microsoft about this in particular and the answer I got back matches what their policy states.  That is, if you’re using a virtual machine backup product that relies on snapshots, that solution is unsupported and you may be redirected to the backup vendor for support.  This is true whether or not the virtual machine backup uses an application aware VSS writer, as some popular backup products do.

When you are virtualizing your mission critical applications like Exchange or SQL, support is extremely important.  So what are your options?

1)  If you have a Microsoft Premier support agreement, then Microsoft will make reasonable efforts to support you even if you run in unsupported configurations.  If your organization has a Premier support agreement then you’ll most likely get support if you use a backup product that relies on virtual machine snapshots.  Always confirm with your Microsoft rep in advance to ensure they will support the configuration.

2)  Talk to your Microsoft representative and try to get the support statement clarified. Show them your configuration and get confirmation that it is or is not supported.

3)  Rely on the backup vendor for first level support if your restored VM is having issues.

4)  Use a different type of backup product for Exchange or SQL virtual machines.

As I said, mission critical applications have more strict requirements for support and I believe that you should make all attempts to follow these requirements.  These applications are usually too important to an organization to risk a lengthy outage due to a miscommunication or disagreement about what is or is not supported.

What is supported?

To start with, one common misconception is that guest clustering is not supported at all in vSphere.  If anyone out there still believes this (and I’ve spoken to many organizations over the years that do), I’d like to state definitively that this is not true.  Guest clustering is absolutely supported by both VMware and Microsoft provided you follow the guidelines from both companies in order to maintain support.

One of the best KB articles VMware has released on this subject can be found here.  It does a great job of summarizing the various supported configurations and goes into some application specific clustering types as well.  I keep this KB article handy and use it frequently in discussions with customers.  The following table lists the supported configurations:

I know many folks are very much against the idea of virtualizing a Microsoft cluster and will argue vehemently against its use.  I can tell you I am most definitely not in that camp – I believe that the needs and requirements of the business should dictate whether or not clustering is used.

Why would you use guest clustering?

Ok so now you’ve seen what’s supported and after looking at that table you’re probably wondering if it’s even worth it.  Is virtualizing a cluster kind of a pain? Yep, you’ll get no argument from me that it’s more difficult.  It prevents you from using vMotion or DRS in Fully Automated mode, forces you to use RDMs, and only fiber channel is supported to name a few.  The largest restrictions are when using “shared disk” clusters, or clusters that require dedicated storage that is shared amongst the cluster nodes.

With all of these restrictions, why would you use guest clustering in the first place?

Guest Clustering vs. vSphere HA

Let’s be clear about one thing: vSphere HA does not provide the same level of availability as guest clustering.  vSphere HA is an awesome feature that can be used in combination with guest clustering, but HA is not application aware and can only protect against hardware and operating system failure.

Application-aware high availability

The biggest reason I see customers using guest clustering is to provide high availability at the application level beyond what native vSphere features can provide.  SQL and older versions of Exchange are two commonly clustered guests.  In particular I’ve worked with a lot of customers recently who have physical SQL clusters running SQL 2005 and 2008, and they are working towards bringing them into vSphere as part of larger SQL consolidation and SQL as a Service projects.

Guest OS patching

Many organizations still use clusters so that they can patch the underlying OS or application without causing an outage to end users.  As covered in the next section, newer versions of Microsoft applications have functionality that can provide this benefit without clustering.  I expect we’ll see clusters used just for this purpose decline as applications improve.

For many organizations, the availability that clustering provides is more important than the vSphere features they lose by implementing it.  It all comes down to what is important to the business.

Alternatives to guest clustering

Of course there are alternatives to clustering that can provide the same or similar levels of availability without the restrictions.  Here are some examples.

Exchange 2010

Newer versions of Exchange support technologies that do not require shared disks to provide high availability.  Exchange 2010 in particular supports Database Availability Groups, which can provide HA down to the database level but does not require any shared disk clustering.  That means it can support vMotion, DRS, and all the other great vSphere features.  You can read more about the Exchange 2010/vSphere goodness here.

SQL Database Mirroring/SQL 2012

SQL has had database mirroring for years, and mirroring can provide similar levels of availability to clusters without requiring shared storage.  And with the release of SQL 2012 earlier this month, Microsoft has improved upon that concept with SQL “AlwaysOn” technology.  AlwaysOn technology has some similarities to Database Availability Groups in Exchange 2010 by providing multiple database copies and recoverability at the database level.

File Clusters

With the popularity of storage arrays offering NAS capabilities, the use of file clusters seems to be declining.  These arrays have multiple controllers and redundancy across the platform that can provide the same or better availability than a traditional file cluster.

Use In-Guest iSCSI

Do you want to combine the enterprise features of vSphere with the availability of guest clustering?  One way to consider doing this is by using in-guest iSCSI to present storage to clustered virtual machines.  Using this method gets around the VMware policy of only supporting fiber channel while still allowing features like vMotion to be used.  This method is by no means an easy solution – you may need to adjust cluster heartbeat timeouts to allow vMotion to operate successfully, networking at the vSphere level becomes more complicated, using multipathing software is more complicated, vendor support may be more complicated, etc.  Again it all comes down to the requirements of the business.

Conclusions

Have I convinced any of you that guest clustering is not the worst thing in the world?  I really hope so, because I don’t think we should ever be so closed minded that we immediately dismiss something because it is difficult to implement.  I am definitely in the camp of folks who prefer to avoid using guest clustering so that I can take advantage of all the great features in vSphere.  But I am most definitely not in the camp of people who dismiss it entirely.

For me, it comes down to what are the needs of the business and how can those needs be met.  There are situations where guest clustering is required, and I don’t think we should be telling organizations to keep those servers physical.  If you want to virtualize mission critical applications then you should be prepared to consider all possible configurations to meet the needs of the business.

Last year I let the voting pass without saying a word since the The Lowercase w was new and I didn’t feel like the content was worthy of promoting just yet.  Though I still don’t feel like I belong even in the top 5, I figured I’d highlight some of my more popular posts over the last year to see if I can earn a few votes.

New SQL 2012 Licensing and its Impact On Virtualization

Fix Partition Alignment with VMware Converter 5.0 (Beta)

vSphere and Exchange admins can live in harmony – Microsoft finally supports HA and vMotion

Clearing up confusion regarding HA/vMotion support for Exchange 2010

Reclaiming disk space with Storage vMotion and Thin Provisioning

And remember to keep the voting fair and honest.  Heck, I didn’t even vote for myself as #1!  You can vote for your favorite blogs by going here:

http://vote.vsphere-land.com/

If any of my posts have helped with your VMware environment or you found them useful, consider voting for The Lowercase w.  Heck, if you just want to vote for someone who won’t stand idly by while the very company we support is humiliated time and time again by folks who can’t be bothered to spell the company name correctly then The Lowercase w will gladly take your vote!

Thanks to all the readers of TLw!

For me the “hardest” VCP exam I’ve taken was the VCP2 (VCP-101) back in 2005.  That exam was based on ESX 2.1 and VirtualCenter 1.0 at the time, and I was definitely nervous to it.  I had been using ESX on and off since early 2002 or so, but made the mistake of waiting 3 or 4 months after taking the required course and taking the exam.  By far I studied the most for that exam than any other VCP exam I’ve taken since, and was very happy with my score.

The VCP2 exam naturally focused on higher level concepts since virtualization was so new to most people.  I remember needing to memorize the definitions of “Encapsulation” and “Isolation” as they related to virtualization.  This trend continued with the VCP3 and to some extent the VCP4, as new features were introduced with each version so the test had questions relating to understanding what things like vMotion and HA were, along with a lot of configuration minimum and maximum questions.

Here is where I felt the VCP5 did a really good job of separating itself from the previous exams.  Instead of memorizing definitions or configuration minimums and maximums, it tested your knowledge of how these features actually work.  Understanding what vSphere HA is and what it does is important, but understanding how HA actually works in specific scenarios is more important.  The same is true for DRS, networking, etc.

So for those that are studying for the exam, if you don’t have any real hands on experience with the product you may find the exam more difficult.  I’d recommend getting a lab setup and playing with the features.  If you’ve used ESX/ESXi for years or at least have been using vSphere for the last couple of years you stand a better shot of passing just based on your experience.  You should still study the new features of vSphere 5 and any changes to the way things work, but having hands on experience is key to passing.

For what it’s worth – I was more apprehensive about this exam than any since the VCP2, probably mostly related to how many new features were added to vSphere in this vSphere 5.  So if you’re worried or intimidated by this exam, don’t worry.  You’re in good company.

I won’t try to provide a list of resources I used to study since others have done that already.  By far the best I have found is by my former EMC Consulting colleague Gregg Robertson.  Check out his list of VCP5 resources.

I left the exam somewhat unhappy with my score (thought I should have done better) but overall pleased with the experience.  Best of luck to everyone trying to get exam completed before the end of February!

I’ve spoken to some folks who have stated that their Microsoft reps have clarified that the 20 core limit only applies to those upgrading to SQL 2012 Enterprise from SQL 2008 Enterprise when using Server+CAL licensing.  The licensing datasheet that was released in November had language that made it seem like that applied to everyone.

Luckily the folks I spoke to were correct – in December, Microsoft released an updated copy of the licensing datasheet that includes language that is much more clear and definitive.  It is now clear that the 20 core limit only applies to licenses that have been upgraded with Software Assurance that use the Server+CAL licensing model.

For reference, here is the somewhat confusing language from the November licensing datasheet (emphasis is Microsoft’s):

Both newly purchased server licenses for SQL Server EE 2012 or EE server licenses with SA upgraded to SQL Server EE 2012 will be limited to server deployments with 20 cores or less.

Here is what the December edition of the licensing datasheet says (emphasis is Microsoft’s):

Legacy SQL Server 2012 Enterprise Edition Server deployments licensed in the server + CAL model will be subject to a 20 core per server license maximum. This core maximum applies both to new server licenses and to prior version server licenses upgraded to 2012 with SA.

To me that is much more clear and definitive on what the 20 core limit applies to.  I’m happy to see this doesn’t apply to all licenses..

You can read more about the new licensing for SQL 2012 by going to SQL 2012 Licensing Overview page.  Here are some of the highlights:

• The Datacenter Edition from SQL 2008 R2, which was previously licensed per socket/CPU, has been discontinued.
• The top tier license is now Enterprise Edition (EE), which is licensed per core.  It requires a minimum of 4 core licenses per processor.  If all cores in a host are licensed, you retain the unlimited virtualization rights previously available in SQL 2008 R2 Datacenter Edition.
• The cost per core of SQL 2012 Enterprise will be $6,874/core not including Software Assurance (SA).
• Software Assurance is required in order to use license mobility (i.e. vMotion/Live Migration) more than once every 90 days.
• Instead of licensing an entire server, you can also license the virtual cores of individual SQL virtual machines.
• Core licenses are sold in 2 core packs.
• There is a limitation of 20 cores per server maximum for EE. (Note: this has been clarified - see below)
• If you are current on SA and have SQL 2008 R2 Enterprise you will receive a minimum of four SQL 2012 EE core licenses per CPU or the actual number of cores in use.
• If you are current on SA and have SQL 2008 R2 Datacenter you will receive a minimum of eight SQL 2012 EE core licenses per CPU or the actual number of cores in use.

Per Core Licensing

It really shouldn’t come as a surprise to anyone that Microsoft is moving from a per socket/processor model to a per-core model for licensing SQL Server.  After all, processors are shipping with more and more cores per CPU and are capable of higher consolidation ratios.  Combine that with the fact that the majority of SQL Server workloads are actually very light use (based on VMware Capacity Planner data) and you can see that Microsoft couldn’t continue with per socket licensing.

The only potential issue I see is the minimum of 4 cores licenses per processor.  If organizations are still using older hardware that only has 2 cores/processor then they are paying for cores they don’t have.  I would suspect that in 2012 this isn’t likely to affect a large number of organizations.

Cost

The actual cost for EE is roughly the same as if you licensed 2 sockets of SQL 2008 R2 Enterprise Edition as long as it had 4 cores per CPU.  The cost goes up as soon as you start using 6 core processors and above.  The prevalence of 4 core processors means this likely won’t change much for many organizations.

Compared to SQL 2008 R2 Datacenter, however, there is a large cost difference.  Datacenter costs $54,990 per processor or over $100,000 to license a 2 CPU system.  You can now essentially get the benefits of Datacenter Edition (unlimited virtualization rights, etc.) for half the cost you would pay in SQL 2008 R2.

Even with this new licensing model there are still huge cost savings to be had by licensing all cores of a server and virtualizing your SQL 2012 workloads.  It’s hard to argue with unlimited virtualization rights especially for those lightly loaded SQL workloads.

There may be situations where Server + CAL licensing actually makes more sense.  If you’re worried about the higher per core costs that may be something to consider.  Server + CAL licensing requires a lot more administrative overhead and is usually only beneficial for situations where there are a small amount of users/devices that are easily accounted for.

Licensing per VM

Instead of licensing all of the cores in a server, you can instead simply license the cores you use in your SQL virtual machines.  Sounds easy, right?  Unfortunately you are still required to license four cores per VM.  Since the majority of SQL workloads are underutilized and can likely get by with 1-2 vCPUs, you’re essentially paying for core licenses you won’t use.  I can’t imagine many organizations will go down this road unless they have a small number of larger SQL servers.

20 Core Limitation

I have to admit I’m scratching my head a bit on this one.  Knowing that 10 and 12 core processors are available today and 16 core processors are on the horizon, why put a limit at just 20 cores per server?  What happens if you already own 12 core processors, or you have a 4 socket system that exceeds 20 cores in total?  The only thing the SQL 2012 Licensing Guide says is to “contact your Microsoft representative for help transitioning to the new licensing model.”  It’s not uncommon for organizations to scale up and have ESX/ESXi hosts with greater than 20 cores (even easier today with 8 and 10 core processors), so I would hope there is a reasonable solution here.

Update 12/19/2011: On December 1st, Microsoft released an updated copy of their licensing datasheet for SQL 2012.  In this updated version, they clarify the language around the 20 core limit and make it clear that it only applies to SQL 2012 EE licenses that were upgraded from SQL 2008 licenses in the Server + CAL model.  For EE licenses that are purchased new, or that were upgraded from SQL 2008 that used the per CPU licensing model, you are not limited to just 20 cores.  See this post for more information.

Software Assurance

If you already have SA on your SQL 2008 R2 licenses, you’re probably in better shape than you think.  Note the italics above regarding “actual number of cores in use.”  If you use per processor licensing in SQL now and your processors have more than 4/8 cores, work with Microsoft to get core licenses for what you’re actually using rather than simply accepting the default trade-in value.  Those that bought into higher core CPUs should not be penalized by upgrading to SQL 2012.

Software Assurance also gives you the right to full virtual machine mobility.  In other words, the rights to use vMotion/DRS in vSphere to move your SQL workloads more than once per 90 days.  You still need the appropriate Windows license to allow that mobility, but again this is another reason why Software Assurance is becoming mandatory.

Final Thoughts

Anyone still reading?  I realize this is a large post so I’ll keep my final thoughts brief.  In short, I think that the move to per-core based licensing was an inevitable change that I would expect to see other vendors take up as well.  The bright side is that the cost to have unlimited virtualization rights for SQL has essentially been cut in half depending on whether or not you already owned the SQL 2008 Datacenter license.

Anything that promotes the virtualization of mission critical applications like SQL is good in my book.  I look forward to talking to customers about this change and helping them move towards virtualizing their SQL deployments.

The original performance report can be found here (opens a PDF): http://www.principledtechnologies.com/clients/reports/VMware/vsphere5density0811.pdf

Microsoft posted a response to the report, but strangely they did not post it on a TechNet blog or other Microsoft branded site.  Instead they uploaded it to Papershare, an online collaboration website for sharing technical papers.  (Side note: Papershare is awesome and I highly recommend you sign up).  All due respect to Papershare but I think it is obvious that they would get more readers had they simply posted the results on their blog.  Maybe they did but I can’t find it.

Here is Microsoft’s response, called VMware vSphere 5.0 Performance Benchmark Reality (Papershare login required): http://www.papershare.com/app/paper.aspx?id=1253&o=6

I wanted to share some thoughts on Microsoft’s findings and where I agree/disagree.  Though I admit this is a VMware focused blog I am by no means a Microsoft basher or someone who simply says “Hyper-V sucks.”  I think that Hyper-V has come a long way and there are definitely use cases for it.

One of the issues that Microsoft has with the memory overcommit test is that a 60 minute idle period was introduced before any testing was run.  That is, the hypervisors were booted up and all virtual machines were started and then 60 minutes passed before any benchmark was run.  Microsoft states that this gives VMware's Transparent Page Sharing feature a chance to scan for and de-duplicate memory pages in RAM and so it wasn’t a fair or realistic test.  They also state that the test is unrealistic because it is 30 identical workloads (ideal for memory sharing) and that most organizations do not run memory overcommit in production.

Finally, Microsoft states that VMware's EULA “restricts” Microsoft from running similar performance benchmarks to validate these results.  Microsoft raises a few other points that I won’t address here so I’d recommend reading the paper.

I actually agree with Microsoft I don’t often see memory overcommit in production.  I most often see it in VDI environments where VM density is more important than the performance gain from using large memory pages.

That said, I disagree with Microsoft’s assertion that the 60 minute idle period gave the vSphere VMs an unfair advantage and time to share memory. First off, does Microsoft believe that organizations only run their production workloads in 59 minute increments?  Even if they disagree with the 60 minute idle period they have to understand that in a production situation these VMs would be running 24/7 so a 60 minute head start really doesn’t give vSphere any advantage.

Second, if the VMs are sitting idle and the application isn’t running then the application’s memory pages are not in physical RAM so there is nothing to share.  Only after the performance test was started and the application loaded memory pages into RAM did page sharing really have a chance to kick in and start sharing application specific memory pages.  At that point the 60 minute idle period essentially made very little difference.

In my experience I don’t often see organizations overcommit memory with business critical/tier 1 applications, though there are certainly use cases.  If the workloads are identical and VM density is important then it actually does make sense.

With respect to the EULA rule regarding performance benchmarks (that has been in place since at least ESX 2.x), my advice to Microsoft is this: Don’t hide behind the EULA - run the test and submit the results to VMware for approval.  I have actually done this in the past and was pleasantly surprised at how easy the process was.  If your testing methodology is fair then I believe VMware will allow publication even if it doesn’t show vSphere coming out ahead.

The results show that in this particular workload without memory overcommit that Hyper-V isn’t too far behind vSphere 5.  Congrats to Microsoft for improving Hyper-V and bringing it to a much higher level. Of course straight performance is only one aspect of the differences between vSphere and Hyper-V and this article doesn’t touch on the many feature differences.

I’m all for fair benchmarking to compare products and reasonable rebuttals if necessary.  However, the fact that Microsoft didn’t publish this rebuttal on their blog is strange, and I don’t completely agree with the logic they used to counter the results.  I strongly believe that if Microsoft disagrees with the results then they should run their own benchmark and submit it to VMware for approval to publish.

One of the interesting things they’ve done in this test aside from scale up/scale out testing is to formally test vMotion and Storage vMotion during LoadGen.  LoadGen, if you are unfamiliar, is a Microsoft tool used to simulate user activity in an Exchange environment and measure user response time.

I won’t spoil the ending of the report, but as expected the vMotion and Storage vMotion operations did not cause exceptions that would cause the LoadGen test to fail.  In fact, the Storage vMotion had almost no impact whatsoever.

This brings up an interesting point – since VMware was able to prove that Storage vMotion caused no impact even during an Exchange performance test, it may be a good candidate for Storage DRS in vSphere 5.  Microsoft has improved the I/O consumption of Exchange 2010 so much that it actually consumes very little I/O at all (relatively speaking compared to previous versions).  Still, Exchange is a mission critical application and heavily utilized Exchange environments could benefit from Storage DRS migrating particular mailbox database VMDKs to less utilized storage to optimize the user experience.  And as this whitepaper shows there is very little impact during the migration.

There may be reasons why organizations would chose to exclude their Exchange VMs from automatic Storage vMotion with Storage DRS.  Some of those reasons could be around compliance, acceptance of this new vSphere 5 feature, concerns about performance, and possibly the impact on backup/DR strategies.  Assuming those could be mitigated, I believe this testing shows that Exchange VMs actually make good candidates for Storage DRS.

I’m curious of what others think, so feel free to leave a comment.