VMware vSphere 5 Licensing—it's not all about vRAM

With the announcement of features and new licensing model for VMware vSphere 5 during a live+webcast presentation, much of the ensuing kerfuffle was aimed at the new licensing model, rather than excitement over the new features. I have to admit, I'm one of those folks who aren't happy with the licensing changes; to be fair, I haven't been happy with the licensing moves VMware has been making since the introduction of "Enterprise Plus."

I understand and can accept the rationale from VMware, including the way the vRAM pooling is supposed to work. I'm also the first to admit that I've got a bias in favor of VMware: I am one of the leaders of the Kansas City VMware User Group in addition to being a long-time customer.

No, my concern is the way VMware keeps tying specific "entitlements" (their term) to the various Editions of vSphere. In this case, I'm not just thinking of the vRAM entitlement—the piece that's generating all the outrage—but the features that are available accross editions.

VMware's licensing whitepaper gives a nice overview of the new model, as well as some examples of how the new model could work in practice, paying particular attention to the vRAM portion. My opinion is that VMware pays short shrift to the other, non-vRAM details that distinguish the different Editions of vSphere.
On the vRAM side: If you have a small cluster of 2-socket hosts with modest amounts of physical RAM (e.g., 96GB/host), you will be unimpacted by the new license model if you're already on Enterprise Plus (2 sockets x 48GB vRAM= 96GB); in this scenario—assuming you have current service-and-support contracts—you'll upgrade straight to the vSphere 5 Enterprise Plus licenses and be "off to the races." Your physical RAM won't ever exceed your entitlement, and if you're over-subscribing your guest memory, you're begging more problems than vRAM entitlements, because it also means you've not left yourself any wiggle-room for N+1 availability. In fact, if you're in that situation, you may have over bought from a vRAM perspective: A 5-host cluster with 10 sockets of Enterprise Plus has a pool of 480GB vRAM. If all those hosts have 96GB physical RAM, your N+1 memory allocation shouldn't exceed 384GB, so you wouldn't need a vRAM pool bigger than 384GB. You can't quite achieve that with 10 sockets of Enterprise (which has a 32-GB entitlement), but you can do it with 12 sockets, which is a tiny bit less expensive (list price) than 10 sockets of Enterprise Plus ($34,500 vs $34,950). Of course, that assumes you're pushing the limits of your physical hardware and not obeying the 80% rule. In that case, you could get away with 10 seats of Enterprise and save a pretty big chunk of cash.

My suggestion to VMware: consider two changes to the licensing model with respect to vRAM entitlements. 1) allow vRAM pooling across editions, rather than keeping it edition-specific. 2) create vRAM "adder licenses" so that organizations can add blocks of vRAM to their pools (without paying for all the additional features of a full processor license at any given edition). Doing both eliminates the need for different SKUs for editions as well as vRAM increments.

Back to the 5-host cluster example...

The problem with going the route of choosing Enterprise over Enterprise Plus just to manage the vRAM pool—and I'm certain that VMware has all this in mind—is that you must give up some pretty cool vSphere features (e.g., host profiles, dvSwitch) if you aren't on Enterprise Plus, including some new features in vSphere 5 (e.g., storage DRS). These features of vSphere make a lot of sense for smaller enterprises that have to watch every single dollar spent on IT, especially when shared storage (which, in my opinion, is the one thing that really makes virtualization sing) is probably the single most expensive item in a virtualization project.
In this case, I'd like to see VMware push some of these more interesting new features down the Edition stack. In general, anything that helps the business better utilize their (typically) very expensive storage investment makes sense. If VMware keeps the storage features at the most expensive end of the spectrum, organizations may be more inclined to consider alternatives for their perceived value rather than paying the premium for Enterprise Plus, especially now that there's the added burden of vRAM entitlements to consider.

iPhone Battery Life: use it or lose it?

I think most iPhone users have discovered that their little "magical" friend has a propensity for chewing through battery life like high-schoolers chew through Doritos. Tips and tricks for extending life abound, but all the ones I've read amount to disabling functionality of the phone or applications.

I accept that keeping the GPS receiver on at all times will be a big drain; there isn't a lot of value of keeping it on when I spend the majority of my day inside and away from windows that could allow reception.

No, the things I don't want to disable are important functions to me. Things like push messaging; that's why I have a smartphone in the first place: to stay in touch and have messages at my fingertips.

So I husband my battery use, and most days am lucky to get through it with at least 30% still showing in the indicator.

But over the holiday weekend, I noticed something: I was regularly staying above 50% by the end of the day. Curious. I wasn't using it any less; if anything, I was on it more, taking pictures, checking social media, etc. What was the big difference?

I think I found it, and you may find it a surprise...

I use Bluetooth (BT) for in-car hands-free and for my Sony-Ericson HBH-IS800 headset. I normally leave the BT radio enabled so the phone automatically connects with the car; the way Apple buried the BT controls in the Settings app is pretty annoying for quick or frequent BT enable and disable, so I take the lazy way and leave it on. And I normally leave the HBH turned off to retain battery life, so the normal state for the iPhone is Bluetooth On/Unpaired.

And that seems to be a huge battery drain; an even bigger drain than having a paired device connected to it.

Here's what happened: this weekend, I kept my phone in my pocket, but didn't keep the HBH with me; I left it plugged into its charger until time came that I might want to use it. I noticed at one point during the day that my phone was paired up with it, however; I didn't realize it could/would do that while charging. I also noticed that the phone wasn't chewing through the battery like usual. So I did a qualitative experiment: One day, I would keep the phone paired with my HBH at all times; the next day I'd keep it un-paired, as usual; and the final day, I'd actively enable and disable the BT radio whenever I actually needed it.

Again; this was qualitative, not quantitative: there are too many other variables at play to put real numbers to it. However, by the end of the experiment, I was convinced: If you want to extend battery life without turning off the BT radio (by far, the best choice), make sure it's paired.

As I understand it, it goes a bit like this: the preferred state for the device—when BT is enabled—is to be paired. With anything. If it's unpaired, the radio throws extra power into trying to see if one of its partners are "out there" trying to reach it. When it's paired—and able to readily "stay in touch" with the partner—the radio draws less power than when it's "seeking."

Rule of thumb: when it comes to BT power consumption, radio off < radio paired < radio seeking

VMware vExpert 2011

I'm not usually in to the chest-thumping thing, but I'm proud to have been selected as a VMware vExpert for the third year in a row (which also happens to be every year the award has been given).

While I like to think I'm a bit of an expert when it comes to VMware, the award is really a recognition of the work I've done to promote VMware—and virtualization in general—through my volunteer work on the leadership team of the Kansas City VMware User Group (kcvmug).

It's been great to be a part of the team that helped grow our VMUG from a couple dozen regular attendees to a group that regularly sees 80+ members at "regular" meetings and 400+ attendees at our annual all-day "regional" meeting.

My thanks go out to VMware for supporting the program, John Troyer for his "above and beyond" efforts to launch and add value to the program over the years, and his anonymous team of judges for giving me the nod. But most of all, I want to thank my fellow kcvmug leaders, past (Kevin Davidson, Ron Armstrong, Ryan Melton, Joe Adams) and present (Ben Clayton, Tony Lux); without you, the VMUG wouldn't be what it is today.