Virtualization juggernaut VMware hits the CPU turbo button for licensing costs Kind old VMware is updating its pricing model in a move to "continue meeting our customers' needs". Provided those needs involve paying more for CPUs with more than 32 cores. You lucky people. Pricing is being tweaked upwards where software is licensed on a per CPU basis. If the chip has more than 32 cores like, say, a 64 …
Might wonder if Intel's been whispering sweet 'nothings' into Dell's ear about keeping them topped up with xeon chippery in an attempt to dissuade enterprise customers from such Epyc tomfoolery...
Me? No... I'd never suggest such a thing... No...
Mines the one with the manilla envelopes in the pocket.
I'm not entirely sure this is aimed at AMD - the combination of Intel doubling up CPU's (to try and match AMD's core counts) and removing the memory tax is likely to have made large Intel systems just as likely as large AMD systems.
And Intel only provide their high core count CPU's as white boxes, cutting out high-end Dell business...
Looking at the economics, paying for enough memory to use all those cores (say 1.5TB for 128 real cores gives you 6GB/core or 3GB/thread to play with) I wonder how much of the market this actually affects - the areas that benefit from lots of CPU are generally IO constrained so you don't want high utilisation hypervisors when smaller units avoid premium memory/CPU prices and afford more resilience for maintenance/hardware failures. I'm not saying there aren't use cases - just that use cases involving high core counts AND VMware AND have no issues with premium hardware prices are likely to be low
While arbitary price increases piss me off as much as the next person.. .it's a good point that you make about the memory requirements and it being a relatively niche target for price gouging.
On the other hand, with the steady move to more parallel processing within individual instances it's a relatively niche hit now however will be rather more so in the future.
How should these things be licensed? By each discrete processing core (the very dubious mess of hyper-threading aside) when things are moving towards more parallel execution. Which at least is a way to have MS Windows properly multi-task (old dig, largely fixed now). Or by discrete chips? It's an interesting conundrum
This comment isn't really related to VMware so read on if you want to. That said :-
This is nothing new. I work in the EU, and was involved in the development and deployment of a fleet-wide (~200+ vehicles) integrated data and management system using cellular routers from a North American equipment manufacturer, mainly on the strength of their 'back end' management platform.
It really was a thing of beauty and flexability, due to their excellent and flexible hardware (Expensive, but good) and the truly excellent back-end that allowed management of the fleet's devices, Settings changes (and therefore the end-user's 'experience') were comparatively simple and near-instantaneous, no matter where the relevant vehicle was in the EU. We re-sold several variants of the system, despite the initial capex being on the high side, on the strength of the back-end management & reporting system.
Licensing changes occurred typically once annually, steadily placing more focus on the management suite until........the per-device licence fee when remotely managed rose ~450% in one go..... instantly a non-viable solution for most of our existing customers - the opex was now seriously (actually prohibitively) unattractive, and NONE of our fleet customers opted to renew their device licences, in most cases switching to an alternative solution.
So...nothing unexpected here. Build a following, achieve significant market share, create 'vendor lock-in' and then monetise the f**k out of the thing - In this case, to death. I'll never recommend their solution again.
It's just business, but it it's not playing the game nicely.
> If you grab too hard, it dies
So what? You've got your executive bonus, then you open your golden parachute and sail to the next job to be botched.
As any board of administration or shareholder meeting knows, concrete short-term profits always trump vague long term perspectives. So yes, you squeeze the last golden egg out of the geese, then butcher them and sell their meat, then sit back and count your profit for that quarter. No point worrying about your job future, anybody will hire somebody with your profit record.
This is neither cynical nor a flame war, but an honest question:
Why would anybody use VMware for virtualisation in more than a Lab/SMB scale?
- If you are so big, that you feel the pain on 33+ core CPUs, you most likely have an IT department
- If you have an IT department, the actual people working there will want the money going in their pockets, not VMware's
- Xen and (even better) KVM cost nothing in license fees and scale much better, the HCL of KVM being ... close to everything ever built on x64.
- Just a handfull of VMware full-featured licenses will easily pay for a BOFH plus a PFY.
- The "ecosystem" (managability, storage options, ...) of the FOSS world have already bridged the gap and are often better than their VMware counterparts.
I am a huge KVM fan (haven't really tried Xen) but I assume VMware has features that are missing from KVM. I am trying to make use of the VMDq feature of intel NICs which is supposed to work out of the box on ESXi under the NetQueue moniker. But I cannot find any information on how to do this. I found some info that Xen 3.3 "will" support this (quite an old post obviously) but I couldn't find anything in the release notes of any Xen version that mentions VMDq.
As much as appreciate it, the FOSS world is not all roses, you know.
Yea I run the xen project in centos 7 moved away from libvirt, kvm and qemu, xen supports HVM and IOMMU as well as PV, I used to use ESXi vmware was a much easier setup to begin with but it didn't feel secure to me and their update system is somewhat rubbish, my dell has issues with the dom0 kernel of Xens though, the 4.9 kernel needs mpt3sas adding to dracut drivers as they are not installed automatically which leaves the 4.9 kernel unbootable. Have to say I think xen is better that the default qemu setup
VMware provides a broadly-featured, stable, and well-supported product. I've been vCenter for over a decade, and compared to my experience with open-source tools, it's much simpler to deploy, scale, operate, patch, etc. And, of course, if something goes wrong, you have VMware's world-class support organization to fall back on. Yeah, it's expensive, enough that my company hasn't licensed some features and products that I would like, but the core hypervisor/vCenter product is worth the price in our case.
Consider as well the fact that companies which have been running VMware for a while will have considerable sunk costs in terms of both licensing and expertise, and migrating from one hypervisor to another is hardly effort-free.
"Xen and (even better) KVM cost nothing in license fees" calls to mind the Jamie Zawinski quote that "Linux is only free if your time has no value." For the "scale much better" and "ecosystem" points . . . [citation needed]. VMware remains the gold standard for virtualization; the only real competition comes from cloud operators (who, admittedly, are scaring the bejesus out of VMware, and rightly so). Unfortunately for VMware, this move to turn the knob on the money faucet may have the effect of causing more enterprise customers to look seriously at cloud migrations if they're not already doing so.
In my employer's case, it's also an informal edict of "software the business runs on at a given SLA must have a service and support contract from the software's author/company"
I need to go look at what VMware's changes entail, but I'm not certain if it is physical core count, or logical core count. We have hyperthreading turned on for the bulk of our hosts, which may or may not be a good thing. (I've read articles recommending both turning off hyperthreading because it's TEH DEVIL and hurts performances, and articles recommending turning it on because it's TEH AWESOME!!1oneone)
Why would anybody use VMware for virtualisation in more than a Lab/SMB scale?- Xen and (even better) KVM cost nothing in license fees and scale much better, the HCL of KVM being ... close to everything ever built on x64.
You need to bolt high-availability monitoring and migration capabilities onto your Xen/KVM installations, whereas vSphere just has it as a check-box.
Legacy systems run far better under VMWare, so just a few of those can steer the decision.
Many advanced VM backup systems are built around VMWare, which don't have equivalents in KVM/Xen. In fact the changed-block tracking or whatever they call it is a licensed feature.
VMWare's vSAN offers HA with distributed storage instead of proper SAN.
You're not completely off the mark, though. If the price goes up much, there are several cheaper alternatives that many companies will be able to make-due with, with only modest sacrifices.
VMWare deserves credit for giving away ESXi for free. That's got about the same level of features you get with free KVM/Xen, so free VMware is an option in there, too.
We've got a decent sized Vmware cluster for our prodution workloads. 3 nodes, 96 cpus 576gig ram. Currently looking to expand this significant actually.
A lot of our stuff is Foss, and Vmware is running around 30 Ubuntu VMs. I have to pick and choose where we spend time tinkering however - I can tinker with our outbound mail server or a specific database but the entire platform the company runs on? I'm not prepared to (and don't have the time) to tinker there. Easier just to pay for it since its mission critical (and we have a provider who supports it too as needed).
Incidentally it still comes out way cheaper than AWS even with the Vmware licence fees.
If you've deep pockets, vSphere is frankly the best on the makret. However if you don't need the very best, datacentre edition of Windows per host gives you their VSAN (Storage Spaces Direct) and unlimited Windows guests for considerably less considering you'd still need licences for Windows VM if using VMWare.
These days for greenfield sites that are a Microsoft shop guest wise Hyper-v covers it off
MS makes their money with licensing in other ways, I assure you. ( like SQL Server; it's licensed for the number of logical cores on the host running the VM containing the SQL engine, even if that VM only has one logical CPU configured.) this is bad news if that single vCPU VM is running on a host with, oh, 56 logical cores...
That's just patently untrue and even when it was true 15 years ago your description is deceptive at best. SQL 2008 (not even R2) was licensed by cores assigned to the VM. The SQL 2005 Licensing *was* per socket and wasn't that bad of a deal considering the core/thread counts in production back in 2005. Seriously go look at the core counts available in 2005; an amateur homemade-explosives enthusiast could count them on one hand.
I get that people hate Msft and their licensing, but it's not rocket science.
This is wrong. Maybe you are thinking of Oracle licensing terms? If you are licensing SQL this way, then you are paying way more than you need to.
You have multiple methods of licensing SQL server, but the most common is to license the number of virtual cores in the VM running the SQL instances with a minimum of 4 cores. If you have SQL Enterprise edition, you have the option to license all the cores on a physical host which then allows you to run SQL in an unlimited number of VMs on that host.
The guide is here:
https://download.microsoft.com/download/7/8/C/78CDF005-97C1-4129-926B-CE4A6FE92CF5/SQL_Server_2017_Licensing_guide.pdf
Page 16 gives you details on licensing in virtual environments.
However you license it, it is the same regardless of the underlying hypervisor, so the VMWare increases will still bite on large systems. HyperV may be a better solution. We have been a VMWare shop for years, but are now seriously looking at alternatives even before this price hike news.
The only people running Hyper-V are the ones in the simplest setup possible.
If you are serious, and have the full SCVMM cluster setup, Hyper-V has already torn your guts out with its issues and problems.
The only shops I've touched that are happy with Hyper-V are single-host virtualizing a few guests. Very happy with the price. Aren't big enough to care about full on clustering, moving VMs from host to host, etc.
Everybody else in the cluster realm can't wait to get rid of it.
Hopefully this is the last major licensing cost change for at least 5 years or so. I would expect it anyway. Of course relieved it could of been a hell of a lot worse, actual per core licensing, or the "vRAM" episode they tried at one point, or even worse still perhaps per-VM pricing which I think some/many of their add-ons have as options anyway.
Of course they may jack up the prices again in general when the next vSphere comes out, perhaps in exchange for adding in a bunch of extra features (such as NSX) that you may not need or want.
My vSphere setups have always been basic vSphere(Ent+)+vCenter. I have looked at the add-ons every now and then and never saw anything that was worth the extra money for me anyway. I priced out the vRealize suite and the cost was high enough I could of purchased a half dozen extra hosts (I'll take the extra hosts in a heartbeat). The core products in my experience are rock solid stable (assuming you are on certified hardware anyway), I have generally filed less than 1 support ticket per year for an actual problem I need fixed over the past 9 years now. Currently running about 900 VMs.
The last Vmware product I was truly excited about was vSphere 4.0(just look how packed that release was https://www.vmware.com/support/vsphere4/doc/vsp_40_new_feat.html ), everything since has been smaller incremental updates, and literally the main thing driving my upgrades was simply for support purposes. I ran 4.1 past EOL, and ran 5.5 past EOL. vCenter 6.7 has a pretty decent HTML UI finally but I'd honestly take the older .NET client in a heartbeat (I say that as someone who passionately hated the .NET client in the early days as a Linux user(still am a linux user), but I changed my mind after I saw the flash and the html clients.
(vmware customer since 1999, ESX/i customer since 2006)
With projects like xen and ovirt, why would anyone pay to use vmware, I mean if you want to deploy to a cluster of servers I would always go for ovirt and if you want a hypervisor like ESXi I reckon the Xen project is a better solution, might not have a nice gui but the foundations are far more sound than vmware if you ask me.
Although this sounds bad, i'm not sure how many IT shops are actually running 32 core CPUs. I've talked to many people at VMworld and they are still on 15:1 maybe 30:1 host to VM ratios. Most people trade depth for less risk. I know plenty of people that are just getting HPE DL360 with 12 - 16 core to build their stack. I'm sure the cost of a 32+ core server is prohibitive for most orgs.
[ 3.308903] smp: Brought up 1 node, 128 CPUs
[ 3.308903] smpboot: Max logical packages: 2
[ 3.308903] smpboot: Total of 128 processors activated (511045.88 BogoMIPS)
I've got ALL the cores :D
And they're good ones. Not crappy vulnerability-riddled intel ones.
I don't care about vmware licensing because I use kvm, and who knows WHAT horrors lurk in vmwares closed source you couldn't pay me :V
I can do one better:
[ 0.542143] smp: Bringing up secondary CPUs ...
[ 1.475483] smp: Brought up 2 nodes, 176 CPUs
[ 1.475518] numa: Node 0 CPUs: 0-87
[ 1.475538] numa: Node 8 CPUs: 88-175
[ 1.475567] Using shared cache scheduler topology
No Intel/AMD vulnerabiliies either -- definitely no (User) Management Engine or Platform (In)Security Processor on these.
License? GPL. "qemu-system-ppc64 -cpu host -smp 176 -m 256G". Eat your heart out VMware.
Ah, bliss...
...though I could use some more RAM....
Wouldn't it be nice to be able make use of all the hardware without any hypervisor overhead... Maybe hardware or logical partitions... Any one for a Z series. Or is this a stepping stone in Intel's plan working with AWS on Nitro systems.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
