Panel only seen by widget owner
Cortex Consulting
Typically replies within a day
Hi there 
How can we help you?
Start Chat
3 Apr 2020

Back in February, before the world changed forever with Corona Virus, I blogged about the impending change to VMware's CPU metric, with a follow up piece on the ITAM Review site exploring the change in more depth.  In the latter post, I confidently predicted that we would see VMware's new definition appear in the April Product Guide document.  As it happens, I was correct - the new document was released yesterday, on the very day that VMware had told us the change would take place and, coincidentally (or not), the same day the latest version of the vendor's flagship product, vSphere, went on general sale.  If you browse to page 6 of the Product Guide terms, you will see the following in section 1, Terms Applicable to All Products.


Exactly as expected then.  For every 32-core block in the socket CPU's of the servers hosting VMware products, you will need a Processor licence.  A socket CPU with up to 32 cores will require 1, up to 64 will require 2, up to 96 will require get the picture.  If you are familiar with the Product Guide, you will know that VMware has product-specific terms as well.  Every product, for which the Processor metric is an available option, now includes a reference back to the clause shown above amongst its terms.  There are also a raft of other changes to the general terms in section 1 of the document, including a definition of Cores which has never previously been included, extending as far as breaking down what VMware regards cores to mean in physical, virtual and public cloud environments.  Following that, there are further definitions of what constitutes a Physical Core, a Processor and a Virtual CPU.

As I said earlier, yesterday also marked the general release of vSphere 7.  If you read my in-depth post on the CPU metric change on the ITAM Review site, you will recall the points I made about upgrades.  To recap, the short version is that if you have SNS (VMware's support offering) on your processor licences and choose to upgrade to vSphere 7, you will be subject to the terms in the Product Guide released yesterday.  I.E. the Processor Restriction noted above will apply as soon as you install the upgraded software.  If you haven't already completed an impact assessment on your VMware estate, do it before you install any upgrades of major, minor or maintenance releases.

And on the subject of maintenance releases, there is an interesting new feature in vSphere 7 which, on the surface of it, won't appear to have a licensing impact but, unfortunately, it most likely will.  The Register noted yesterday, in its piece about the product release, that this version will have the ability to "non-disruptively update itself and ensure that hosts run your preferred software and firmware".  This has come from the vendor's SVP for Cloud Business, Krish Prasad.  Casting your mind back to my previous posts, you will hopefully remember the point I made about product releases and the applicable version of the Product Guide.  In section 1.3 of the guide, it tells you that the terms of the PG that is available when you install a new maintenance, minor or major release will apply to your use of the software.  Jumping over to VMware's current SNS terms (updated Sept 2019 at the time of writing), clause 1.9 defines a maintenance release as a generally available release of the Software that typically provides maintenance corrections only or high severity bug fixes.  So, if vSphere 7 is able to self-patch automatically, as an ITAM manager, you'll need to liaise very closely with your virtual infrastructure teams to ensure you are on top of the licence terms that apply to you.

If you have any questions or comments about the above, please feel free to reach out to us.  If you need help understanding the impact to your VMware estate, please get in touch - we can conduct a full assessment that will ensure you don't full foul of the complex licensing scenarios in play here.