Decoding the new Broadcom VMware vSphere Licensing Packages (for Small Deployments)

That is a smart cash grab on their part. Due to current socket pricing and cores, Most people went with 32 core CPU’s.  2 CPU’s 2 licenses, away we go.   Keeping that in multiples makes sense. 

Now, this is where it gets sneaky.

SQL Enterprise licenses. Not even remotely cheap. Also based on core count.  I have multiple clusters of SQL Enterprise and to keep costs down, we had dual CPU’s but significantly lower core counts, with higher speeds.   We were using Dual 6 core CPU’s before that were blazing fast, They no longer make them. One cluster of 4 hosts, dual 6 core CPUs = 48 cores.  During an upgrade of that cluster I had to switch to 3 hosts, 8 cores per cpu and that was still 48 cores. No change 8*2=16*3=48

Targeting people with SQL Enterprise seems on par with what has been going on. Obviously we are a big enough shop, to A, have the money to pay for extra VMware licenses, and B, will have a bit harder of a time migrating away quickly. SQL Enterprise usually means we are using things like Always On and have some pretty critical systems we are not going to trust on another hypervisor without a lot of testing. 

Also, some little customer with 2 small hosts is most likely not worth their time right now in this transition. Sure, it’s income, but when you add in support and all the other added costs, they are looking specifically for profit. Large profit. If you get rid of 50% of your small customers, and keep the 50% that you make the most of, you can downsize staff and have higher profit margins overall.

This one will 100% effect me, but I don’t know how much yet. 

I will say this. While everyone is trying to wrap their heads around this, I’m not going to worry about it for a while. Too many rumors, overreactions and unknowns still. Whatever route they chose, was 100% thought out and planned. It may not be ideal for ME, but I can’t change it, and they know what direction they want to take. 

The product is still good for now and works great. If work don’t want to pay, we’ll switch, if they do want to keep paying, even better. I’ll do my job and cut costs where it makes sense.

 @dloseke, As mentioned by others, I’m watching and waiting to see what shapes up for Service Providers as well, given they were always licensed very differently to end-user agreements. 

Ruh roh…

https://www.theregister.com/2024/01/10/broadcom_ends_vmware_partner_program/

Keep in mind, this article simply references the fact that Broadcom has ended the VMware partner program. That information came out almost immediately after the acquisition finalized. I’m not really sure why the register wrote this article so *long* after the information came out, but it added nothing of value to the discussion other than quoting people that don’t know what’s going to happen next.

This information you screen capped here is far more interesting and valuable than that article. 

Great summary Derek.  I am waiting to see how our Partner status moves with them now but we have been assured we are good.  Hopefully it does not change much for us.

That’s a whole different animal.  I was concerned about not even maintaining a partnership with VMware due to the new Partner Program being invite-only.  However, after some deeper reading, Broadcom has published that they intend on bringing along all active partners.  That is, all Partner’s that have had an active contract in the past year.  However, I believe partnership levels will be affected based on their information published.  But most folks don’t quote know where they will fall.  More of that information should be coming out by the end of the month with emails going out to the primary and secondary contacts for each partner.  There is/what a lot of FUD around the initial annoucements, but I think it won’t be as bad as folks assumed early-on.

 

 

 

Seems a lot more information has come out about how the non service provider crowd will deal with licensing. I’m still waiting to see how service providers will be affected.

 

The Register article is referencing CSP’s being dropped, whereas the almost immediate press release just listed Partner, and not specifically CSP’s as far as I know.  With that said, there’s be a huge lack of information all around from Broadcom, so it wouldn’t surprise me if they sat on some of this info as well before publishing as there certainly has been changes where they reversed course briefly, etc.  I will note that since I’m not a CSP, I don’t get to see the CSP-specific information in the Partner Connect portal.

Now I’m seeing reports of partners not being invited into the new Partner Program unless they are bringing in $500,000+ in annual revenue.  I personally haven’t gotten an invite into the program yet, and we for sure do nowhere near 500k as a small MSP.  The frustrating part is that if we end up terminated as a partner, how do we procure licensing for our clients?  To my knowledge, that information hasn’t been released and I know others are asking the same question.  

I also find it interesting the shear amount of opinions and information that is being released/leaked.  Broadcom said they would handle this acquisition better than they did CA and Symantec, but I agree that it sure doesn’t seem like they’re doing that.  If feels like they’re very much targeting enterprise customers and are pretty much leaving SMB’s out in the cold. 

 

https://www.theregister.com/2024/01/18/broadcom_vmware_channel_disruption/

Uau!!! It is a big bomb in the MSP market!

I remember seeing this table and it being the motivator to go with 32 Core CPU’s as why not cram in all the performance in to a single Host as possible to save cost. It still makes sense to have host density to save costs in infrastructure. 

The only thing that changed is the minimum. Here’s the thing though. Previously if you bought a 6 core CPU or a 32 Core CPU, you used 1 license.

This holds true if you have an 8 or 16 core CPU now

The difference is, once you get over 16, you will be paying significantly more. 

If you run 8 core CPU’s, and I have 32, my bill is going to be higher.  Sure you will pay the same as the guy with 16, but both of you will pay less than me.  I guess they have to draw the line somewhere, and you can’t even buy 4 or 6 core XEON’s anymore.

Here was the old model.

I do understand the limit of 32 per socket. People were angry with this when they implemented it as well, but eventually we’ll see 128 then 256 cores per socket and density only increases. It’s the same reason Veeam is using VUL’s. The only options are license per core, or continually jack up the price to meet density. With the Per core, VUL, or other type of license like this, I buy it and pay for what I use. With per socket, as I double my VM’s, and my support tickets, you better believe they have to double their price at some point. 

Now, this is unfortunate for people with 8,10,12 core CPUs’, but hopefully long term it’s better than increasing the price of socket based licenses to account for 60 cores

On our website about VMware, we translate the latest VMware by Broadcom licensing information into Polish https://ht.poznan.pl/przejecie-vmware-przez-broadcom-nowe-zasady-licencjonowania-subskrypcja-i-koniec-licencji-dozywotnich/however, there is a lack of regional (per country) VMware webinars on this topic. Customers are completely confused and we ourselves do not know what the prices and price lists of the basic versions of vSphere will be. I.e. are available on partner websites but how can you find them among 16,000 items and this is a price list valid until January 31, 2024 :(

Very useful article! However, to be VERY PRECISE, in the section "vSphere Subscription Licensing Scenarios" instead of "(2) Hosts, 16 Total Cores per Host (or less)" shouldn't it rather be "(2) Hosts, 16 Total Cores per Host (or less) IN ONE CPU per Host"? As far as I undertand, If we had "(2) Hosts, 16 Total Cores per Host (or less) but IN TWO CPU, 8-core each CPU" would mean that you have to count: 2 (hosts) * 2 (CPU) * 16 (cores minimum per CPU) = 64 cores.

Am I right?

yes proxmox backup is not as feature rich as veem...so we we should encourage veem to support proxmox, but also Proxmox is free and Proxmox backup is also free, so if you don’t need all those “extra features”, than yes Proxmox is a good alteritive that does include free backup. 

This is how I understand it to be as well.   Standard licensing is not just per core but Per Core per CPU, with a minimum 16 core commit (again per CPU).  So if you have two hosts with dual quad core CPUS, with standard you would need to licenses 16 X 4 Minimum.
 
Looks like standard features have changed since perpetual: https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/docs/vmw-datasheet-vsphere-product-line-comparison.pdf

not sure if it changes...probably not, but previously when the eval subscription or vmug sub (which is probably the most similar) ran out, the result was:
“For ESXi hosts, license or evaluation period expiry leads to disconnection from vCenter Server. All powered on virtual machines continue to work, but you cannot power on virtual machines after they are powered off. You cannot change the current configuration of the features that are in use”   Which likely results in the APIs for backup shutting down, so veeam backups will stop too.   

Added reddit link on the topic: https://www.reddit.com/r/vmware/comments/19faifh/new_vsphere_subscriptions_behavior_once_product/

Yeah, I had to correct my posting a couple weeks ago because I had initially believed that Broadcom followed the same licensing standard as Microsoft where it was a 16-core minimum per host, but it was pointed out and I have corrected that it’s a 16-core minimum per CPU.  Meaning, if you have dual 10-core CPU’s in a host for instance, you need to buy 32 cores of licensing for that single host.  Assuming 2 or 3 hosts, it may make more sense to buy an Essentials+ Kit for 96 cores vs buying the same in Standard unless you need the Standard feature set. That does significantly narrow the gap where Standard may be cheaper for smaller deployments if you have multiple sockets per host. I probably need to further clarify my table on exactly how that total core count is derived.

I’m fortunate in that a couple years ago my recommendation for my clients when scoping hardware was to purchase single-socket servers with 16 cores so that we still were safe on a per-socket count, but were buying right up to the core minimum for Windows Server and not leaving anything on the table for performance while not having to pay extra for additional cores.  That strategy is playing out in the long run for me, but we do have some clients with RAM-dense hosts where we had to utilize dual-sockets and thusly it’s going to cost more come “renewal” time to stay with VMware.

Thank you, I’m glad I was able to help!