Last night I posted an article where I showed my initial findings in regards to the changes in vSphere Licensing. In the post I showed just how much more VMware customers will have to fork out to upgrade their environments to vSphere 5. I also included some tables which showed the figures.
After looking into the licensing issue a little deeper, and after spending some time on the phone with my good friend Tom Howarth (from http://www.planetvm.net), I realized that the whole licensing thing isn’t as straight forward as my original post might have pointed out. I’m going to try and explain myself and Tom’s findings.
The first conversation I had with Tom this morning really turned into a session in which we had exchanged our feelings of disbelief and annoyance in regards to where the new licensing model would leave our customers. About half an hour to an hour after that conversation had finished, Tom gave me another call in which he said: “It’s not as bad as we had first thought”. I guess that is what really (indirectly) triggered this post.
Both Tom and I did some calculations on our own and came to the same conclusion. Although we are not entirely in favor of the new licensing model, it does seem to, in certain conditions, force you to stay with recommended best practice in regards to N+1.
I’m going to try and start off with some simple examples to illustrate just what the new licensing model would mean in terms of money.
Bear in mind that in vSphere 5, the licensing will be based on “pools” of resources which I understand is per “vCenter Server instance”. I assume that licenses can move around not only between clusters, but data centre objects as well. However, I could be wrong, so don’t quote me on that just yet.
For simplicity, I’m going to assume that we have a single vCenter server that manages a single cluster of ESXi hosts.
In my first example, I’m going to keep it real simple. In this example we have a single ESXi host being managed by a vCenter server. The ESX host has two 12-core CPUs and 64GB of RAM to start with. The calculation looks as follows:
In the table above, we see that it actually costs more to run vSphere 4 Enterprise than vSphere 5 Enterprise or Enterprise Plus. Also, notice that we require more vSphere 4 Standard and Enterprise licenses as what is required for vSphere 4 Enterprise Plus as well as all of the vSphere 5 Editions. This is because of the 6-core CPU limit on vSphere 4 Standard and Enterprise Editions.
Other than that, there’s not much else to say about the calculation above, so let’s double the memory in that host to a figure that I’m more likely to see more often in my customer environments.
Ok, the table above shows a little more about the penalty that will be paid in terms of vRAM TAX. Because there is now more than 96GB of RAM, an extra CPU license is required to legally make use of use of 100% of the physical memory.
However, as a single host is not very realistic, I’m going to up the ESXi hosts to 4. Let’s see what happens.
The table above shows 4 ESXi hosts. Although the licensing looks bad, keep in mind that we are planning to use 100% of the physical memory in the host, which is not a good idea in terms of HA and N+1. It is also very bad design practice.
So to get ourselves into a better position in regards to HA, let’s apply a rule that states we have to leave 25% headroom in terms of cluster wide memory.
As a result of applying a rule that states that we are only allowed to use 75% of the TOTAL cluster’s physical memory resources, the licensing seems to be more on target, with an equal license count between vSphere 4 and 5. Also, because of the CPU core limit in vSphere 4, notice that with the Enterprise license, vSphere 5 actually works out cheaper than vSphere 4.
Now here’s the trap. Let’s up the Target Physical memory Utilization figure to by 1% to 76% and see what happens.
As soon as we use 76% of the cluster wide physical memory resources, we are required to purchase another license. The biggest issue I have here is that VMware now contradicts itself in terms of features and licensing. For example, they would like to sell vSphere as the “clever” solution that will sort out resource contention with things like Resource Pools (Proportional Share-Based Algorithm) and Transparent Memory Page Sharing, but on the other hand, they tax you for using those features.
In the figure above, vSphere 5 is more expensive as we only have two CPU sockets in each host and are aiming to utilize 100% of the physical memory. As said before, this is a bad design!
The figure above shows that with the reduced Max physical memory utilization of 75%, vSphere 4 and vSphere 5 is on equal footing in regards to price. However, the catch is detailed in the graphs below:
The figure above starts to reveal the vRAM tax. Simply because we use 1% more than 75% of the physical memory, we now require an additional CPU license on vSphere 5
Now the figure above shows just how the vRAM tax is applied. The next figure will make it even clearer.
Ok, so we can clearly see that from the images above, based on 128GB of RAM per host, which I have to say, based on my experience, is an average amount of RAM for today’s blade systems, the penalty get’s heavier and heavier with every host you add to the environment.
Now, if you do end up in a situation where you need to purchase additional licenses, the only thing that can think of to cushion the blow a little would be to double the amount of physical processor packages in each host, if you have the empty sockets available to do so. Probably the worst thing I can think of is having a situation where you have more licenses than physical CPUs and still have empty CPU sockets. At least, by filling the empty CPU sockets, you’ll have the option of additional CPU resources.
