Month: July 2011

So I promised to follow up, and here I am. I briefly touched on the new licensing structure the other day, and left with the words “DON’T PANIC”.

I stand by my words today, and here’s why:

The vRAM-based license entitlement is only a factor of what needs to be observed. We still need to purchase licenses per-socket, the virtual memory entitlement is pooled at the vCenter level, and we only need to worry about it for VMs that we’ve powered on. We no longer need to be concerned about the number of cores per socket or physical memory limitations in the host.

Let’s think about this for a moment.

Say I’m a small shop – I figure I need 3 hosts to virtualize my physical environment (say, all of 30 hosts). So I shell out for 3 dual-socket, 4-core hosts, with 32GB of RAM each, and vSphere Standard licenses all around (maybe I saved some cash and bought Essentials or Essentials Plus – those both use the Standard license). 6 total licenses are necessary, each giving me an entitlement to 24GB of vRAM. 144GB of vRAM total. If I virtualize each of my physical machines and give them each 4GB of RAM, I’m looking at 120GB of vRAM allocated. I’m still 24GB under my entitlement. Sure, I’m overcommitting a bit, with only 96GB of physical RAM available to the cluster, but at the same time, I’m going to guess that all of those hosts don’t require 4GB of RAM.

In this scenario, I still have room to kick each host up to 48GB of RAM before I really have to worry about memory overcommitment in earnest.

But let’s take this scenario out just a little farther. I’ve upgraded my hosts to 48GB of RAM each, and as my environment’s grown, I’m finding that I’m getting ready to overcommit memory. I know my environment, and realize that a little bit of overcommitment isn’t a bad thing. I just need to buy 1 more vSphere CPU license, and my vRAM entitlement grows.

Or let’s throw another curveball – instead of upgrading RAM, I replace my hosts. I keep the memory specs the same – 32GB each, but I get get new boxes with 8 cores per socket. In vSphere 4.1, that meant either upgrading my licenses to Enterprise Plus, or purchasing an additional, say, Standard license for each socket. Now, all I have to do is turn up the new boxes, remove the license from the 4-core node, and reapply it to the 8-core node. Problem solved, and no more money spent on software.

What about a fairly large shop? What if I’ve got a pair of 20-node clusters running a ton of VMs?

My large shop has been virtualizing a long time, and has a virtualize-first policy. It has also matured its provisioning processes to go along with virtualization. Virtual machines in this environment are generally provisioned with 1GB of vRAM. The hosts are 4-socket, 6-core systems. We’re running Enterprise Plus. This gives a 48GB vRAM per license entitlement. This means that I can deliver 3840GB of vRAM to each cluster. 3800VMs per cluster (assuming the VMs are provisioned with 1GB vRAM each). Now, that’s 192 VMs per host, which is fairly uncommon consolidation as far as I’ve seen.

The highest consoidation I’ve seen (with my own eyes) is 60:1. But more typically, I tend to see closer to 20:1. Even at 4GB vRAM per VM, at 20:1 consolidation, you’re still only allocating 80GB of vRAM per host, which is well under the 192GB of vRAM entitlement based on the 4 sockets licensed on the host. That gives us a lot of breathing room.

Sure, your VMs will vary in size, 1GB here, 8GB there, but the point is still the same. In most cases, your licensing will not cause you any trouble in most cases. I really think that most customers will find better flexibility in this new licensing model.

What’s even better is that the vRAM entitlement is pooled in a vCenter, so you’re not stuck with a workload on one host.

Change is tough, but it’s not as bad as it may seem at first glance.