Editor's note: For the latest on domain controller virtualization, check out Gary's follow-up article on virtualizing...
DCs from June 2010.
Server virtualization has received increased attention from IT managers who see it as a way to stretch their already thin budgets. Getting one machine to act like and do the work of two or more machines is a really powerful tactic and one that is gaining popularity for application servers. With virtualization software supporting 64-bit platforms and soon to be supporting IA-64 Itanium microprocessors, the limits may be expanding -- and that's good news for IT managers.
In general, virtual application servers are working quite nicely, but many IT managers are also exploring the idea of virtualizing domain controllers (DCs). That enthusiasm, however, leaves the administrator with several unanswered questions: Is it really a good idea to virtualize domain controllers? What are the ramifications? Does Microsoft support it?
Microsoft's view of domain controller virtualization
Microsoft has published a white paper, Running Domain Controllers in Virtual Server 2005, as well as KB article 888794, entitled "Considerations when hosting Active Directory domain controllers in virtual hosting environments" to address this issue. We can deduce that it is indeed possible to host DCs on virtual machines merely by the fact that these documents provide "How to" guidelines for accomplishing the task.
However, there are some very specific guidelines for virtual DCs. Some important points include:
- Recommended placements of virtual DCs include branch office sites with a small population (20 or less)
- Recommendations for where not to place virtual DCs:
- Don't place them in locations where mission-critical services like Exchange require a domain controller
- Don't use them to host Flexible Single Master Operation (FSMO) roles
- Don't use them as Global Catalogs for Exchange servers
- Don't use them for bridgehead roles
Note: This, of course, assumes the use of Microsoft's Virtual Server product.
Ramifications of domain controller virtualization
In evaluating the feasibility of virtualizing any server role, it is important to note that the main resources used on a busy DC are RAM and Disk, which are also the two things that virtualization isn't the greatest for sharing. Remember that the RAM of the physical machine is divided up between the host and the virtual machines, so physical RAM becomes a very critical resource. To be sure, disk space is a big issue, especially if you make backups by saving snapshots of the virtual machines. CPU resources on DCs are usually a non-issue, yet they are the primary reason given to justify virtualizing servers.
I personally only know of a few companies that actually implement virtual DCs in production. For example, there is one large global corporation with an Active Directory architecture that is only virtualizing "Lag Site" DCs (See my tech target article Preventing Active Directory disaster: The replication LAG site). This company does not virtualize all DCs because of possible I/O bottlenecks. Another issue is security. In a virtual server, since the domain controller is basically a file, it could get saved and later mistakenly booted from that file, having the effect of an out-of-date DC coming back online and injecting lingering objects in the AD. Of course, that file can be compromised, mistakenly deleted or even copied to steal data.
What about support?
Another issue to keep in mind is supportability. Does Microsoft support virtualization of DCs if you call for it? The answer is … it depends. According to Microsoft KB article 897615, Microsoft will support DCs loaded on its Virtual Server product. However, if you use EMC Corp.'s VMware product (which I prefer), then the level of support will vary.
Here are some other points to remember, according to KB 897615:
- If you are not a Microsoft Premier Support customer, then you will have to reproduce the problem on a single physical machine to remove the virtualization software.
- If you are a Microsoft Premier Support customer, then the company has said it will make efforts to investigate any potential issues, but may still require you to reproduce it on a physical machine.
In other words, if you aren't using Virtual Server, then all bets are off. Thus, when deciding whether to virtualize your domain controllers, you must determine if you are prepared to live with this support condition. Are you really willing to reproduce a critical error that is stopping replication and affecting application of Group Policy on a separate machine rather than the one it is failing on? This will obviously take time just to set up and you may never be able to repro the problem, which may or may not be the fault of the virtualization software.
Best practices for virtualizing DCs
To summarize a few best practices for virtualizing DCs:
- Follow the guidelines in Microsoft KB 888794 and the Microsoft white paper "Running a Domain Controller in Virtual Server 2005."
- Start out by implementing virtual DCs in non-critical roles such as LAG DCs.
- Follow specific policies and procedures that detail backing up and physical management of the backups of the files that comprise the virtual machines including physical access to the host machine and disks.
- Remember that pausing a virtual machine or turning it off and then turning it on again later will have the same effect as removing a DC or Global Catalog from the physical network. That is, starting it up again can inject lingering objects into the Active Directory.
- Make sure the host can handle the load (I/O, memory, disk space and performance).
- You will probably NEVER want to put all or even a majority of your DCs on virtual machines. If you follow Microsoft's recommendation, you won't virtualize GCs that are used for Exchange, FSMO role holders or other roles where performance is critical.
- Remember the supportability issue. Do you really want Microsoft to tell you that you'll have to install the DC on a physical machine and reproduce the problem? If you have a critical outage, it will make a bad situation even worse, forcing you to add in the time to reproduce the problem to the problem-resolution time. I don't know how many times Microsoft has required a customer to do this, but it is definitely worth considering.
Any domain controller virtualization design should come with a great deal of analysis and testing. While there are not a lot of case studies out there to prove or disprove many of the points made here, it should be sufficient to convince any IT manager or administrator that virtualization of DCs is possible and supported. Your mileage may vary: Implement it in very limited, non-critical roles, and go from there.
ABOUT THE AUTHOR:
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Directory Services and formerly for Windows File Systems.