Domain Controller in a VM

Chiefcrowe

Diamond Member
Sep 15, 2008
5,050
194
116
So i am planning to add a domain controller to my domain in a VM. The first one is on a physical machine.
In your experience, what are the things I need to watch out for/make sure of when I do this?

thanks!!
 

theevilsharpie

Platinum Member
Nov 2, 2009
2,322
14
81
Make sure that the system time in the VM is correct.

Otherwise, I'm not aware of any special requirements for running a DC in a VM.
 

BoT

Senior member
May 18, 2010
365
0
86
www.codisha.com
the VM should have a dedicated NIC, a good chunk of memory but other then that i don't see any other special requirements
 

Chapbass

Diamond Member
May 31, 2004
3,145
93
91
Yep, nothing super special about it. We do this at work regularly. Usually a good idea to have at least one physical one, but the benefits of virtualizing stuff are awesome, and DC's are usually relatively simple creatures :)
 

Reliant

Diamond Member
Mar 29, 2001
3,843
0
76
Nothing too particular, just keep a DC on real hardware incase the VM environment goes down. About half of our 20 DCs are VMs, and no issues.
 

Nothinman

Elite Member
Sep 14, 2001
30,672
0
0
Yep, time sync is the only real gotcha. And having a physical one available to be brought up first so that DHCP and DNS are available for everything else, including the ESX hosts, is always a good idea.
 

seepy83

Platinum Member
Nov 12, 2003
2,132
3
71
the VM should have a dedicated NIC, a good chunk of memory but other then that i don't see any other special requirements

I don't see much reason for dedicating one of the ESX server's NICs to a DC VM. Why are you recommending this?
 

BoT

Senior member
May 18, 2010
365
0
86
www.codisha.com
primarily for performance and availability reasons.
example: having a single gigabit connection and 10 VM NAT'ing through it via the host machine will bring it to a crawl quickly. since i am not to concerned with a clients VM being slow, for a DC, DNS, DHCP, Exchange server and the likes i would rather not for that to happen.
dedicating a physical network interface can prevent even the possibility of that to happen.
both virtualbox and hyper-v can NAT through the host/server but prefer to have a physical interface as well
 

yinan

Golden Member
Jan 12, 2007
1,801
2
71
That is not really a recommended practice or anything even close to VMware's best practices because you are introducing a single point of failure for that VM.
Also, if you have DC traffic saturating a gig link you have other problems. DC traffic is very, very small.
NATing an internal server to clients is also not very smart and just makes the networking side a whole heck of a lot more complicated.

Also, if 10 clients conencting to a VM brings your host to a crawl then you need a bigger host and/or upgrade to 10GBe. At work I have a couple thousand virtual machines connect to another virtual machine and it is not slow at all.

Do not follow BoT's advice.
 

Nothinman

Elite Member
Sep 14, 2001
30,672
0
0
primarily for performance and availability reasons.
example: having a single gigabit connection and 10 VM NAT'ing through it via the host machine will bring it to a crawl quickly. since i am not to concerned with a clients VM being slow, for a DC, DNS, DHCP, Exchange server and the likes i would rather not for that to happen.
dedicating a physical network interface can prevent even the possibility of that to happen.
both virtualbox and hyper-v can NAT through the host/server but prefer to have a physical interface as well

Even a 486 can handle hundreds or thousands of SPI records being created and torn down per second, if your ESX host is struggling with 10 then you've got a configuration issue somewhere.

And I may be wrong, but if you dedicate a physical NIC to a VM that kills any HA for that VM. VMware vSwitches can handle the load, so there's very few reasons to ever give a VM a dedicated NIC, you just don't do that.
 

yinan

Golden Member
Jan 12, 2007
1,801
2
71
And I may be wrong, but if you dedicate a physical NIC to a VM that kills any HA for that VM. VMware vSwitches can handle the load, so there's very few reasons to ever give a VM a dedicated NIC, you just don't do that.

It kills it if he uses the NIC as a passthrough device. If he creates a vSwitch on each host dedicated to that VM it would work, but be very wasteful.

Other than that agree 100%.
 

Scarpozzi

Lifer
Jun 13, 2000
26,391
1,780
126
http://technet.microsoft.com/en-us/..._controller_virtualization_hyperv(WS.10).aspx

There's a downloadable .doc version of that. It's pretty thorough. As said before, timesync and disk caching stuff should definitely be looked at.

We've virtualized a bunch of Exchange 2010 servers including the Mail stores here...I wouldn't advise it, but if that works....DCs should be a breeze.
I do recommend having 2 physical and 2 virtual. You should double up on REAL hardware instead of virtual hardware and make sure your DNS is rock solid.
 

yinan

Golden Member
Jan 12, 2007
1,801
2
71
There is absolutely nothing wrong with virtualizing Exchange. We have servers here that each serve a couple thousand users that are Vms with rather low hardware specs too, only 4 vCPUs and 24 GB ram each.
Every server should be virtualized, there are no good arguments for a physical box once ESXi5 comes out and gets rid of the annoying 2 TB limitation.
 

dawks

Diamond Member
Oct 9, 1999
5,071
2
81
One thing to remember, you can't restore the virtualized OS from imaged (vmhd file) backups when you have other AD servers running. They will be out of sync, and start complaining. Users wont be able to log in (without a TON of fixes). So the standard of backing up system state data is the way to go.
 

Emulex

Diamond Member
Jan 28, 2001
9,759
1
71
also if you pause (snapshot) a DC you can have time skew when it comes back online. 5 minutes is all you get with AD (default). I'd run a physical with the least features and run two across two vm hosts both can do dhcp/dns/etc. be sure to backup the vm's at the same time preferably during a low activity time so they are sync'd. there's a big huge doc from the esx guys on guidelines for DC's in a VM.

here read this:

http://www.sole.dk/post/how-to-conf...s-with-resulting-big-problems/?p=387#more-387
 

Chiefcrowe

Diamond Member
Sep 15, 2008
5,050
194
116
Thanks everyone. Yes i am not planning to do snapshots or pausing.

I was a little unclear - So by default, is every guest VM set to sync to the Host OS?
It seems like at least if the VM is in a domain it syncs to the domain controller. Therefore, it seems to me that a 2nd or 3rd domain controller would sync to the primary one? is that true?
 

Nothinman

Elite Member
Sep 14, 2001
30,672
0
0
Thanks everyone. Yes i am not planning to do snapshots or pausing.

I was a little unclear - So by default, is every guest VM set to sync to the Host OS?
It seems like at least if the VM is in a domain it syncs to the domain controller. Therefore, it seems to me that a 2nd or 3rd domain controller would sync to the primary one? is that true?

VMware tools has an option to sync the guest with the ESX host every minute, but I'm not sure if it's on by default or not and it can interfere with other timekeeping methods like NTP.

Technically there's no primary DC like there was with NT domains, they're all just DCs now with one or more DCs holding the FSMO roles for the domain. I believe whichever DC is also the PDC Emulator is the time source for that domain.
 

imagoon

Diamond Member
Feb 19, 2003
5,199
0
0
One thing to remember, you can't restore the virtualized OS from imaged (vmhd file) backups when you have other AD servers running. They will be out of sync, and start complaining. Users wont be able to log in (without a TON of fixes). So the standard of backing up system state data is the way to go.

restore image, boot to AD recovery, set "non-authoritative restore" setting. Reboot.

It is actually pretty trivial. With 2008 (R2) doing "stale records" now you can actually skip the above step if you want to be really bold.

EDIT: yes I still keep system state backups. AD isn't as fragile as it used to be but there is no reason to be stupid about it ;)
 
Last edited:

Scarpozzi

Lifer
Jun 13, 2000
26,391
1,780
126
There is absolutely nothing wrong with virtualizing Exchange. We have servers here that each serve a couple thousand users that are Vms with rather low hardware specs too, only 4 vCPUs and 24 GB ram each.
Every server should be virtualized, there are no good arguments for a physical box once ESXi5 comes out and gets rid of the annoying 2 TB limitation.

Well......CAS & HTS are great as virtuals. We use NetBackup here and have had a lot of problems with VSS consistently backing everything up with the nbclient. Using Windows Server Backup locally, it works great....but the remote client seemed to have a lot of problems with the virtuals. (possibly a resource thing) The mailstores are configured on their own luns, but I think since they were built on VMFS, it's not being 100% fair when it comes to performance. I didn't set it up...but feel that giving the mail servers their own dedicated hardware will remove the bottlenecks....wherever they may be....and allow me to sleep better knowing that backups execute 95%+ of the time rather than 30% of the time...I'm tired of dealing with out of control logs.
 

imagoon

Diamond Member
Feb 19, 2003
5,199
0
0
Well......CAS & HTS are great as virtuals. We use NetBackup here and have had a lot of problems with VSS consistently backing everything up with the nbclient. Using Windows Server Backup locally, it works great....but the remote client seemed to have a lot of problems with the virtuals. (possibly a resource thing) The mailstores are configured on their own luns, but I think since they were built on VMFS, it's not being 100% fair when it comes to performance. I didn't set it up...but feel that giving the mail servers their own dedicated hardware will remove the bottlenecks....wherever they may be....and allow me to sleep better knowing that backups execute 95%+ of the time rather than 30% of the time...I'm tired of dealing with out of control logs.

Seriously doesn't sound like vmware issues. VSS errors and the like are windows errors not vmware errors. Most testing puts VMFS at only aroud 1-2% overhead IE 100MB/s > 98MB/s with IOP actually being better in some cases.

Seems a bit of a stretch to dump VMware because netbackup fails....
 

Emulex

Diamond Member
Jan 28, 2001
9,759
1
71
veeam works perfectly and you can create a sandbox off the backups without modifying them to test your AD world to see how it works. but you know the whole tombstone thing if you are a small company and don't make any changes at night you probably will never run into that problem. if you are doing changes to your AD all the time then that's the problem. you can shut down both AD servers and back them with veeam. for two dedicated machines with dedupe/compress/host based CBT takes about 10 minutes. If you can't restore that you are going to have major problems when your tornado hits and nukes the whole building. also an off-site AD server isn't a bad idea.
 

Scarpozzi

Lifer
Jun 13, 2000
26,391
1,780
126
Seriously doesn't sound like vmware issues. VSS errors and the like are windows errors not vmware errors. Most testing puts VMFS at only aroud 1-2% overhead IE 100MB/s > 98MB/s with IOP actually being better in some cases.

Seems a bit of a stretch to dump VMware because netbackup fails....

It probably isn't the VMware layer, but it does add enough mystery to make troubleshooting more difficult. Typically, 10:00-11:30am, we'll see indexing slowness within the system...and again between 5pm-7pm when backups start running. That's only on VMware...not the physical mail stores. I know a lot of the backup issues have been resolved in the past week by changing around some Exchange settings...but they were specific to running Exchange Server in a VMware environment from Symantec.

I just think for the cost of a real blade server, it's worth the money to know there's no virtual hardware bottleneck when the system is indexing mail or getting hit with multiple large listserv deliveries/SPAM storms and daily mail storms caused in that 10am hour. (busiest time of the day)