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?

HP ProLiant MicroServer – Not Quite There Yet?

When HP announced their new ProLiant MicroServer, I really hoped that it would be the perfect answer to a specific use case I’ve been looking at lately.

Basically, what I’m looking for is a small chassis, low noise branch office server that would be used to host a single virtual machine, offering Read-Only Domain Controller (RODC) and Distributed File System (DFS) file-shares.

Initially it looked to fit the bill perfectly:

  • Small footprint; Check
  • Low Noise levels; Check

But, sadly, that’s where it stops. The first version of the HP ProLiant MicroServer comes with one CPU offering, namely theAMD Athlon II NEO N36L which isn’t all that much to run even a single-VM ESXi instance on.

The current tech spec page does not go into much details about the storage controller, other than it’s an “Integrated 4 port SATA RAID Storage Controller”, which makes it impossible to check for compatibility on the official VMware HCL.

The 1GbE NC107i NIC supplied with the server, seems to be supported by VMware though, at least according to the ProLiant option VMware support matrix.

I understand that HP created this server for a different use-case than the one I’m outlining here, and you can’t really criticize them for that, I just hope that this is just the first of several offerings from HP and that the next version comes with better CPU offerings.

A proper CPU would make this baby the perfect entry level, small footprint, low noise branch-office server.

Update: Simon Seagrave has posted as “somewhat” more verbose analysis of the HP ProLiant Microserver: New HP Proliant MicroServer – a decent vSphere lab server candidate?. His conclusion is pretty much the same as mine though; give us more CPU and a vSphere supported RAID controller and we’re all set. I couldn’t agree more.