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)
License Cost incl. Support
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.
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.
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.