VMware vSphere Hypervisor Licensing and Cost

We all know, and love, the fact that vSphere Hypervisor is free of charge. The free version doesn’t come with all the bells and whistles of the fully licensed product, but it’s still very usable in many scenarios.

Recently I’ve been investigating the possibilities of running vSphere Hypervisor on a number of floating branch offices, also known as vessels.

I’m not going into details about the proposed setup, and how we intend to roll it and so on, but one of the things I really wanted to get out of this was to have all my off-site vSphere Hypervisor installs appear in my vCenter Client. I don’t need HA, DRS, DPM or any of the other licensed features and I’d be happy with running the free edition if only it was able to connect to an existing vCenter installation.

Sadly, and understandably, this isn’t possible in the free edition so I looked into what it would cost to license the installs to make this a possibility. After investigating a bit, it seems that I would need to buy VMware vSphere Standard licenses for all the vessels to be able to get what I want.

For 20 vessels, with the standard pricing available on vmware.com, inclusive 1 year support, we come up with this (all prices in USD)

Hosts vSphere Standard
License Cost incl. Support
Total Cost
20 1318 26360

In effect, this means that I would need to pay $26360.- USD to be able to get my vSphere Hypervisor hosts connected to my existing vCenter. That simply isn’t feasible in the current situation.

Remember, I do not need any of the other features that vSphere Standard provides me with, like Thin Provisioning, High Availability, vMotion, vStorage APIs for Data Protection and Update Manager. Update Manager could potentially be useful, but that’s about it.

So, dear VMware; Have you considered this scenario at all? I’m sure I’m not the only customer looking to deploy vSphere Hypervisor in remote locations, where they will run a single VM and their poor admin wants to be able to have them all managed in a single console?

I would really like to see a “vCenter Connector” license for vSphere Hypervisor, that only provides a way to connect to an existing licensed vCenter instance.

Is this to much to ask for? I understand that VMware want to get paid for their enterprise products, and I’m normally happy to do so, but in this case the return simply does not warrant the cost.

P2V a Domain Controller? Why would you?

Some topics seem to pop up at random intervals, one of them being virtualizing Microsoft Active Directory Domain Controller servers. The question is often either “Should I virtualize my Domain Controllers, and if so should I virtualize all of them?” or “Should I do a P2V (Physical 2 Virtual) conversion of my existing Domain Controllers, or create new ones?

In this post, I’ll be talking about the second question. While there is a lot to be said about the first one as well, I’ll leave that for future post.

Most businesses have an existing Active Directory when they decide to virtualize. There might be different reasons for going virtual with regards to Active Directory, but in my mind there are close to no scenarios where I would even consider doing a P2V conversion of an Domain Controller.

The reasons for this are plenty:

  • You need to do a cold conversion
    You absolutely should not do a hot P2V migration of a DC. If you try to hot migration, you will end up with a domain controller that is out of sync with the others, lots of issues and a really painful headache
  • Never power on the old server
    The old server, the one you did a cold P2V migration of, must never be powered back on after the new virtual instance is started. If it gets powered back on, you will once again be in a world of hurt.
  • Potential Cleanup problems
    You need to clean up the old driver stack (most P2V tools will do this for you), and you might end up with for instance two network cards that share the same IP, one of them hidden from view and not very easily removed. This could in turn make the DNS services on a converted domain controller does bind to the wrong network interface. And we all know what happens to Active Directory if DNS doesn’t work right.

I’m sure there are many other potential issues as well, like Kerberos authentication or trust failures and so on. This is not a situation you want to end up in, especially not in your production environment.

Gabrie van Zanten recently published a recipe for P2V migrations of existing Domain Controllers, called Virtualizing a domain controller, how hard can it be? and I’m confident that this method would probably work out fine.

My question is this; Why would you want to do this in the first place? It’s not like it’s hard to set up a new Domain Controller, make sure it replicates properly with the existing physical or virtual ones, transfer any FSMO roles the soon-to-be-decommissioned Domain Controller has to the new instance and then safely and timely remove Active Directory from the old server.

Of course, Gabe has a point when he mentions that the issues you might get with a botched P2V of a Domain Controller would be the same as old style bad management like using Symantec Ghost on a DC and roll back to an old image if something fails, but why risk it at all?

Deploying a new Windows Server 2008 R2 VM, running dcpromo and setting up DNS does not take a long time, nor is it very complex to do.

I have not timed this, but I seriously doubt that creating a cold P2V migration boot device, shutting down the physical server, booting the cold migration tool, do the actual P2V conversion and powering on the new VM takes less time than it takes to set up a new VM. You might argue that you will have to install anti-virus and backup agents and possibly other tools to the new VM as well, but if your infrastructure is somewhat reasonably set up with automation tools etc. this should not really be a factor to consider. Besides, if you do it this way you have a return path, after all you haven’t removed anything!

In fact, I’m pretty sure this whole post took longer to write than it would take to actually set up a new Domain Controller in my production environment.

My conclusion is, don’t bother risking a P2V of a Domain Controller. Set up a new VM instead, it’s easy, quick and risk free.

In other words, as the vSensei would say “just because you can, no mean you should”

So Gabe, as far as this one goes; You’re on your own! ;-)

Redesigning the vCenter Client?

In fresh blog post, called “Resource pools and simultaneous vMotions” by Frank Denneman prompted a quick Twitter discussion regarding the vCenter client (and perhaps even vCenter itself). A simple

Why are there no folders under Host and Clusters view ?

from Maish Saidel-Keesing got the ball rolling.

Could it be that the design of the client itself helps perpetuate the myth the resource pools is an organizational unit, one that should be used as a way of grouping VMs? As Frank says;

This is not (the) reason why VMware invented resource pools.

I’m not going to get into why this is a bad idea, both Frank and Duncan will have far more intelligent feedback to you if you are interested in discussing this.

Now, if you could redesign the vSphere Client, based on your own experience, what would you change?

I can see that in many cases, a lightweight vCenter Simple Mode client would do the trick. Give your VM admins the Simple Mode client, and they won’t have to worry about resource pools, HA/DRS and other advanced features. Let them administer the VMs, like adding networking, powering on/off etc. The same applies for your storage admins. Give them a small, limited, client that only allows them to configure storage aspects.

I know you can do most of this with permissions etc, but I still feel a limited client could be one way to go.

In other cases, like mine, it won’t help splitting up the client into smaller chunks. As in most SMBs, I wear a lot of different hats during a normal working day. I’m the networking-/storage-/operating-systems-guy in a small shop, where there simply isn’t room for delegating all these tasks to specialized teams or even other admins.

Perhaps dividing the client into specialized sub-topics would help?

A task based user experience where you can select between “VM Operations”, “vSphere Operations”, “Storage Operations” or “Network Operations” as your initial choice, and then limit what you can configure based on your initial choice would help organize the screen real estate? You could also have sub-sections like “Monitoring VMs”, “Monitoring Storage” and so on, displaying a performance overview as the initial point of entry.

You could still have an “Advanced Mode” that works the same way the vCenter Client works today, but the default would be a simplified experience that is based on the task you have at hand.

Am I completely out on a limb here, or is this semi-rant making some sense, somewhere? What would you change, and how?