New SQL 2012 Licensing and Its Impact On Virtualization
Last week Microsoft released their updated licensing scheme for SQL Server 2012, which is due to be released next year. Though there are a number of changes to the product and to how it is licensed, in my mind the biggest change is that Microsoft has moved to a per core licensing model for SQL. The Server + CAL model still exists as well but for this post I’ll focus on the per core licensing and changes that affect those that want to virtualize SQL Server 2012.
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. Update 11/19/2012: Microsoft has included a core multiplication factor that will account for older systems that have fewer than 4 cores per processor.
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.
Update 11/19/2012: Another aspect of per VM licensing that may be undesirable is the requirement to purchase extra licenses if you use Intel processors with hyper-threading enabled. See this post for more details.
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.
I too am a bit upset about the 20-core limit, considering I have a 40-core server being deployed right now.
However maybe Microsoft are capping the core licensing at 20 cores. If you refer to the Edition Overview (http://www.microsoft.com/sqlserver/en/us/future-editions/sql2012-editions.aspx) it states that Enterprise can use the “OS Max” number of cores, however the licensing limit is 20 cores.
Could this mean that 40 cores would be 20 cores licensed and 20 cores free?
Hey Craig,
Thanks for the comment. I have to admit that I seriously doubt Microsoft would give the other 20 cores away for free. My guess is that once you hit the 20 core limit you’ll have to pay for the remaining cores another way. I think that 20 core works fine for now since there are so many 4 core CPUs out there, but it will quickly become a hinderance as 8-16 core CPUs become the norm.
Hopefully Microsoft clarifies their stance once the product gets closer to release.
Thanks again for reading..
Matt
Hi Matt,
I’ve had a read at your excellent article and also the Microsoft licensing datasheet and I think I see where some confusion has arisen over the 20 core limit. According to the datasheet the 20 core limit applies where you have purchased the Server + CAL version of the licensing. As this version of licensing for EE is being phased out what they are saying is that you can upgrade your Server+CAL license to 2012 but it will only be valid for up to 20 cores. If you have/need more cores you need to switch to the Core license model.
Does this help?
Craig
Hey Craig,
Sorry for the delay in responding.
Since this blog post was written, it looks like Microsoft released an updated version of the licensing datasheet that is a bit more clear. It does make it more clear that the 20 core limit applies only to legacy licenses that are upgraded to SQL 2012 Enterprise. I’ll go on shamelessly believing that Microsoft updated their guidance based on this blog post, but I’m going to assume they figured out it was confusing enough all on their own.. 🙂
Thanks for the comment and for reading!
Matt
Quick note – I updated this blog post as well as posted another clarifying the 20 core limit.
http://www.thelowercasew.com/sql-2012-per-core-licensing-clarification
This is where things get confusing.. vmotion/DRS = mandatory SA if used more than once in 90 days. Correct me if i’m wrong but vmotion is used to transfer physical servers to virtual servers and I assume it is not active in load balancing the hypervisor or the servers VMWare is using… is it the same for SQL Server 2012?
is their a scenario where SA will not need to be purchased in a vmware solution?
Hey Wad,
The tool you’re thinking of to transfer physical servers to virtual servers is VMware Converter. vMotion is used to migrate VMs from one physical host to another without incurring any downtime. DRS performs the automated load balancing by performing those vMotion migrations automatically based on demand.
You can get away with configurations where you do not need SA if you really want. In those scenarios you’ll use DRS rules to tie virtual machines to specific ESX/ESXi hosts so that they cannot move around except in the event of a host failure. After a host failure you’d need to adjust your rules to pin the VM the new host for a period of 90 days in order to stay in compliance. In that scenario you could avoid SA and still be able to virtualize your SQL VMs, though you’re missing out on a lot of the benefits of virtualizing SQL in the first place.
In general though I’d say that getting SA on your SQL (or almost any Microsoft) license will probably end up being more of a benefit than just a financial burden.
Hope this helps and thanks for reading!
Matt
I have read that for each VM, you will need to license a minimum of 4 core licenses. Doesn’t this make the virtualizing SQL seriously cost prohibitive? The benefits of HA and VMmotion just got really expensive and difficult to work around. When you look at a single server with 1 quad proc. you would need 4 core licenses. If you put 4 VMs on there, then you would need 16 core licenses, correct? and what if you want to fail over to another box that has a single 6 core proc. Does that mean you need 24 core licenses?
Also, have you heard of any work arounds on this yet, or suggestions to reduce cost?
Hi Trey,
Thanks for reading and commenting.
You’re correct that you can license the individual virtual cores of a SQL virtual machine if you wanted to, but at least today I don’t see a lot of reasons to do this. This may become more popular if you have multi-core servers but only a small number of SQL VMs.
In most other cases it makes more sense to license the physical CPU cores in the ESXi host rather than the individual virtual cores for your SQL VMs. In your example, you would only need to license the 4 physical cores in the host. If you license those 4 cores with SQL 2012 Enterprise, you’ll be able to virtualize an unlimited number of SQL VMs on that host. That would mean that you would license 4 physical cores and then you would not have to pay individually for the 4 VMs you plan to run in your example.
For failover scenarios, you’d have to license all of the physical cores in the ESXi host(s) that could potentially run SQL VMs. But again if all of the cores are properly licensed, you can run an unlimited number of SQL VMs and still use vMotion/HA without any penalties. Since most SQL instances are not heavily utilized, this can present an opportunity to consolidate SQL instances into your vSphere infrastructure and potentially save a lot of money on licensing.
Hope this helps, and again thanks for reading!
Matt
In other words, many customers couldn’t justify paying for 4 years of SA to get 1 upgrade so we know they’ll have to pay for it now so they can keep it virtualized.
Hi Matt,
great article thanks – question though – The unlimited virtualisation costs you refer to above… do your calculations actually include the mandatory SA required to get unlimited virtualisation?
Please advise
Many thanks
Gerard
Thanks for the comment. I didn’t include the cost of SA in any price estimates. I tried to stick to retail prices since actual pricing can vary between different organizations.
After reading this article I have a better understanding in order to get new license for our esx environment (vmotion). Thank very much for the time and effort in it
by the way do you or could point to the right direccion of a video or slides of a virtual environment regarding to the new 2012 sql license (no mcrosoft)
Thanks very much
Hi Matt – good post. I am struggling with use-case justification of licensing the EE on all physical cores (if you don’t need EE product features). The way I see it, this only works if you have a plethora of SQL Servers doing very little IO or real work. Wouldn’t it be more beneficial to consolidate the DB workloads into fewer instances and license them individually (i.e. per VM core or SERVER+CAL)
If you have a bunch of SQL Servers doing REAL work (i.e. high IO, network and CPU) it seems pretty risky to me to cram all those workloads onto one server just to fit into the licensing box of EE entitlement. Architecturally speaking, doesn’t it make more sense in those cases to go SERVER+CAL w/SA and spread those SQL workloads across a number of cluster hosts?
Hey Pierre,
Thanks for the comment.
I agree that licensing EE for all cores is not for perfect for every use case, but probably most that I’ve seen. As a consultant I’ve seen lots of organizations with hundreds of SQL servers that can really benefit by consolidating down to fewer, more powerful hosts along with the unlimited virtualization rights that EE + SA provides.
I think that saying that it only applies to SQL servers that are doing “very little IO or real work” isn’t really a fair statement. Even if the SQL servers are utilizing 4-8 vCPUs (or more) and have high I/O requirements, there is still a justification for virtualizing them. With the scalability of vSphere 5 along with the power of modern servers that have 20 or more cores per server and suddenly that isn’t so hard to virtualize anymore. If you have dozens of SQL servers all with extremely high I/O and CPU usage then it may still work to virtualize them but obviously more careful planning would be required to make sure you can still meet their performance requirements.
The Server + CAL model really doesn’t scale well unless you have a fixed or very easily countable number of users. For many of my customers who use SQL as the backend to web applications it is impossible to license that properly on a per user basis so per core is the only (and preferable) option. If you’ve got a smaller number of SQL servers and/or a small user base that uses the applications then I agree that Server + CAL may cost less, but make sure you consider all of the requirements and needs before going down that road. I personally think that the benefits of licensing EE extend beyond just consolidation and cost savings with the introduction of SQL 2012 AlwaysOn Availability Groups. That feature alone is worth it to many organizations that are tired of dealing with traditional Windows Failover Clusters. Again, all comes down to requirements.
I think the point you’re trying to make (and one I probably should have made more clear in this post) is that it all comes down to your individual requirements. For some licensing all servers with EE may not make sense financially or if you don’t need the features of EE. And for others Server + CAL may still be the better of the two licensing options. I can say from my own experience that the vast majority of the customers I’ve worked with will benefit and save money by switching over to EE licensing and consolidating.
Thanks again for reading and commenting!
Matt
Matt, Great write up and responses.
I am still a bit confused.
I am just getting ready to move to a virtual environment, ESXi 5
• Model: Cisco UCSC-BSE-SFF-C200
• CPU Cores: 12 CPUs x 2.533 GHz
• Processor Sockets: 2
• Cores per Socket: 6
I currently have one SQL 2005 that I will be moving the DBs over from.
I am interested in the BI version of SQL 2012 for the Self-Service BI (Power View, etc…)
I’m not sure what licensing I need.
Thank you,
Mike
Hey Mike,
Thanks for the comment.
The SQL 2012 BI version is only licensed in the Server + CAL model as opposed to the per core licensing model. If you’re only moving over that single server then you’d need to pay the license cost for the SQL 2012 BI edition plus any CALs that you need.
The key questions here are the following: What version of SQL 2005 are you running now, and do you have current Software Assurance on that SQL 2005 license? If you do, then you’re at a minimum entitled to use SQL 2012 Standard Edition and could likely just pay for an upgrade to the SQL 2012 BI Edition.
If you have more than just the one SQL server that you’re moving into your virtual environment then it may make sense to look at SQL 2012 Enterprise. Not only does it contain all of the features of SQL 2012 BI (and more), but it also offers unlimited virtualization rights. It doesn’t make sense in all scenarios but if you have a lot of SQL servers you’re looking to move into your environment then you should take a look at it to see if it’s worth it.
If you’re only moving that one server and you don’t have SA then your answer is simple – you’d buy SQL 2012 BI plus as many CALs as you need.
Here’s a link to the latest SQL 2012 licensing guide (opens a Word document): http://download.microsoft.com/download/4/F/7/4F74E127-827E-420D-971F-53CECB6778BD/SQL_Server_2012_Licensing_Datasheet_and_FAQ_Mar2012.docx
Hope this helps. Thanks for reading!
Matt
Awesome this is a great end to VMware for SQL server! Convince an executive to pay the same to lose performance, have flaked out reliability, and not have true HA. Ha, right you can’t 🙂 Well the VM guy is going to say well we will license VCPU’s….LOL… so now you’re paying for hyper threaded processors that you get for free on physical. Boy what a selling point. Good bye VMware! Go riddance! Don’t you know cheaters never prosper?:-)
Great reason to not virtulize SQL, why would i pay more to go slower with addtional management overhead? Makes no business sense at all. I can use more reliable technology, keep it simpler and achieve the same if not better licensing reductions on physical, plus it scales unlike vmware with a 256 lun limit, not to mention vmware has poor performance under heavy load, and just flakes out even with dedicated ram, cpu, …all best practices in place. This is the third version of this garabage I have tried to virtulize VLDB’s with and its still the same crap.
Hi, This is a great article and I have one question that I am struggling to find an answer for.
Can I buy licences for SQL Server 2012 for my current VM setup and upgrade the licences in 6 months once the servers have been replaced and more cores are available?
I only ask as we have an infrastructure implementation due in six months but I dont believe we have that long on Standard edition 2008 R2 as the data is growing rapidly.
Hey David,
To confirm, you’re asking if you can you upgrade your SQL 2012 license from Standard to Enterprise in the middle of the year (or whenever)? That answer probably depends on how you’re licensed now so it’s hard to say. I would suspect the answer is yes but you should contact your Microsoft rep or MS partner rep to know for sure. If you have an enterprise type license that is renewed once per year based on your actual usage, then you should be able to perform the upgrade and simply “true up” at the end of the year. Again, speak to your licensing rep to be sure as there are many different Microsoft licensing programs.
On a related note, if you wanted to perform an in place upgrade from SQL 2012 Standard to Enterprise on the same server that is allowed. This link (http://msdn.microsoft.com/en-us/library/ms143393.aspx) shows the supported versions for a SQL 2012 edition upgrade and shows you can go from Standard to Enterprise. This link shows the procedure you’ll follow to actually do it (http://msdn.microsoft.com/en-us/library/cc707783.aspx). I know you’re not specifically asking for this but just in case you need to work that into your plans.
Hope this helps!
Matt
Hi Matt,
Thanks for the quick reply.
Yes I’ll get in touch, it would initially be a purchase of SQL Server 2012 Enterprise Edition on our current infrastructure but in 6 months we will be getting a new more powerful server with additional cores.
I wasn’t sure if we needed to re-buy our licences as we are changing servers/ adding more cores.
I’ll check the links out thanks
Dave
Oh ok, now I understand better. So you’d already own SQL 2012 Enterprise, but would be migrating the databases to a new server that has more cores than what you purchased? I think that situation should be even easier – you’re just buying additional licenses rather than upgrading to a different version of SQL 2012. Again it comes down to how you’re currently licensed but I don’t think this will be a big deal.
Don’t forget that you’ll need to maintain Software Assurance if you want to be able to use vMotion (what Microsoft calls “license mobility”) in your environment.
Best of luck!
Matt
Hi Matt,
Nice post you have written here.
I am just confused about one aspect re the number of Cores microsoft will give to customers with 2008 R2 under SA.
We have 3 hosts each has 2 x 6 Core processors. (36 Cores)
Currently we have this lisenced with 6 EE 2008 R2 with SA which is due to renew in a few months time.
When we submit our inventory in order to recieve the maximum 2012 Cores, Should we expect 36 Cores.
Or because we have hyperthreading enabled (2 threads per core) = 64 Logical cores, Will we be given 64 Cores ?
Hope this is not too confusing? It is just that Microsoft claim each thread is treated as a logical core in terms of licensing.
Hey John,
I would expect that you would receive 36 core licenses based on your current inventory. Microsoft will want you to run a tool like Assessment and Planning Toolkit to quantify the number of cores you currently have and then should give you the equivalent number of core licenses.
Hyperthreaded cores shouldn’t be taken into account here. In the latest SQL 2012 licensing guide, it states “Core license needs are equivalent to the cores in a physical server multiplied by the core factor for that server.” That indicates (to me at least) that they are only counting physical cores and not the hyperthreads of a core. I know that they will make you purchase core licenses for hyperthreaded cores if you license on a per-VM basis (see http://www.thelowercasew.com/licensing-sql-2012-in-a-vm-with-hyper-threading) but in terms of the trade-in I doubt you’d get equivalence for hyperthreading.
As always, speak to your Microsoft representative to get an answer specific for your environment. But that said I’d expect you’d get the 36 cores and not more.
Matt
Wow thanks for the quick respons Matt,
Yes we have the MAP toolkit to generate the reports,
So i guess what your saying is that as long as they give us the 36 Cores and we continue SA we can continue running unlimted VM’s and are covered and that we dont have to worry if hyperthreading is turned on or off.
John – you are correct. If you convert your licenses to 36 cores of SQL 2012 Enterprise Edition and maintain SA then you can run an unlimited number of SQL VMs on those three hosts. Then you don’t have to worry about disabling hyperthreading or trying to license based on it. I would definitely turn it on, especially in the more modern Intel processors, as it has been improved a lot and ESXi can take advantage of the improvements.
Hope this helps!
Matt
Hi Matt, We have two 4 ESX server cluster. We have two SQL VM running on one of the ESX host on the cluster.We have licensed the induvidual SQL VM with a 4 core license ( SQL 2012 STD) so total we purchased 8 core license..What is the requirement now to support the Vmotion for SQL server so that the SQL server can move to any one of ESX host on the cluster..
Is it enough if we have only the SA for these 8 cores or should we license 8 cores on all of the 4 ESX hosts to support the vmotion ( meaning we have to buy 32 cores)
Please help to clarify on this
Hey Gopi,
I believe you’re correct – you should just have to license the 8 cores with SA in order to enable you to use vMotion on those two SQL Server virtual machines. This doesn’t help you scale beyond just the two virtual machines but should be enough to allow vMotion.
If you plan on deploying more than just those two SQL Server VMs then you should consider licensing the ESXi hosts instead.
It can’t hurt to confirm with your Microsoft rep as well.
Matt
Hi Matt, we have a ESX cluster with 4 ESX hosts..On one of ESX host we have two SQL VM’s running licensed with 4cores of sql 2012 std edition each ..
Now to support the VMotion for the SQL VM so that the SQL VM can move to any of the other 3 ESX hosts on the cluster what is the licensing requirement ??
Should we buy only the SA for the 8 cores of sql 2012 std edition license ??? Or should we buy 8 cores sql license on other 3 ESX hosts in the cluster .. Meaning we have to buy total 32 core licenses to support the VMotion ???
Please help to clarify on this ??
Regards
Gopi
Hi, Matt. In VMware HA is it possible to force all the SQL Server VMs to failover to the same host (or designate a specific host for failover) in an HA failover scenario? With four ESX hosts in an HA cluster, each with 16 cores, I would like to license SQL Server Enterprise for unlimited virtualization on one host. I would like to license just 16 cores and pin them to that one host, but I’m afraid if the host goes down VMware HA will spread the VMs among the other 3 hosts instead of moving them all to one host and I’d be out of licensing compliance…
Thanks, Ben
Hi Ben,
Thanks for reading and commenting.
It is possible to pin virtual machines to a specific ESXi host by using DRS groups and the “Must run on” or “Should run on” rules. These rules enforce whether the virtual machines either should run on an ESXi host (under normal circumstances), or whether the VMs must either run on that host or not at all. With a should run on rule, the SQL Server VMs will all run on that host unless that host fails. If that host fails, the VMs will be restarted on other hosts. You can use DRS affinity rules to enforce that the VMs all stay together and run on the same host.
With must run on rules, if the ESXi host fails then the SQL Server VMs will not restart on another host. Unfortunately, the only true way to enforce licensing compliance is to use the must run on rules. If you used the should run on rules, then if your host failed and the SQL Server VMs started on another host you’d be out of licensing compliance. Or at the very least you’d have to reassign your SQL Server core licenses to the other host and keep your SQL Server VMs on that host for at least 90 days (not 100% sure on that – that’s how it used to work but that may have changed).
Does that make sense?
Matt
Thanks for the reply, Matt. I’m fine assigning SQL Servers to a new host for 90 days (all hosts are identical so I don’t care if I leave them on a different host indefinitely). But from my understanding of licensing during a host failure all the SQL Server VMs need to stay together, and if they move they can’t move again for another 90 days. Do you know if VMware is capable of those restrictions using the “must” rules? Something like “must stay together” and “must not move again for 90 days”?
Thanks,
Ben
Hey Ben,
Sorry about the delay in response – I missed the notification of your comment!
You’re correct that if you’re only licensing the processor cores of one ESXi host for maximum virtualization (SQL Server 2012 Enterprise), then in the event of that host failing you need to reassign that license and then the workloads can’t move again for 90 days.
With DRS rules you can configure “Must run on” rules to enforce that VMs only run on a particular host. If that host fails, the VMs won’t move and they won’t automatically fail over. You’d need to manually intervene and change the DRS rules to allow those VMs to start on a different host. That would extend your outage and is probably not ideal, though technically required to enforce licensing compliance.
Another option is to use “Should run on” rules to say that VMs should run on that host under normal circumstances, but in a host failure they can run elsewhere. You can combine that with DRS affinity rules to enforce that those VMs always run together. The problem with that scenario is that during a host failure, the VMs might end up running on separate hosts temporarily until DRS is invoked (automatically) and it enforces the affinity rule to bring them together again. That scenario would technically leave you out of compliance.
If you can afford to license more than one host then you have some flexibility and can still use the Must run on rules without requiring manual intervention if a single host fails. Unfortunately there is no provision in vSphere to say “This VM can’t move again for another 90 days.” The other option, if you don’t have a lot of SQL Server VMs, is to license the individual virtual cores instead of the host itself. You’d lose unlimited virtualization but mobility is a little easier.
I would speak with your Microsoft rep if you still aren’t completely sure how it would work in your scenario. Licensing SQL Server can be annoyingly complicated.
Thanks again for reading and sorry again for the delay!
Matt