One-to-one dedicated processors to virtual processor for virtualized Domain Controllers

  • Last Post 28 July 2016
BrianB posted this 26 July 2016

All:   I am being advised by a consultant that there is a need to have a 1:1 ratio of dedicated host processors to virtual domain controller processors when running Active Directory in a virtualized infrastructure. If I cannot get a 1:1 ratio, I am being told that Exchange, lync, etc. need to not share the processors that the Domain Controllers are using on the hypervisor or it can cause performance issues on the domain controller.

  I am trying to find official documentation from Microsoft or hypervisor vendor that states this so that I can bring it to management to dedicate the proper resources in the hypervisor for hosting virtualized DC’s. I am going to have a difficult time convincing my management to dedicate all of the necessary real processors in the virtual infrastructure to my DC’s or at least keep other services from sharing the processors used by my virtualized domain controllers without some sort of documentation stating this.   I have tried to Bing/google it but have not been able to find the statement anywhere. Does anyone know where that declaration is located or is this just a general rule of thumb or “best practice” and is not necessarily a law? Or, is this incorrect advice?   Brian Britt    

Order By: Standard | Newest | Votes
bdesmond posted this 26 July 2016

That’s a new one for me…


Exchange has some guidance around the ratios they recommend on Technet for Exchange specifically, but, I don’t recall ever seeing any guidance for AD. I also can’t

recall ever running in to this at a customer before.


I would treat this as simple capacity planning. Your hypervisor lets you oversubscribe resources. To an extent, that’s fine. If your DCs are running at 20% CPU averaged

across 4 cores, you’re not using 4 cores on the host so you might as well let another load take another X%. If you oversubscribe the host such that you are consuming more resources than actually exist, then you’re going to have perf issues. That’s no different

on AD or any other app you host.




Brian Desmond


(w) 312.625.1438 | (c) 312.731.3132



kebabfest posted this 26 July 2016

I have had Virtualised DCs on the same hosts as Exchange VMs for ages and never came across that as being an issue either.


slavickp posted this 26 July 2016

Neither law nor good practice, as AD is very easy to scale out or (on VM) up, as long as you have available resources. I’d be more concerned about Exchange, that is really CPU-intensive.


sbradcpa posted this 26 July 2016

AD isn't a vast resource hog in my experience.

I'd ask where this consultant is getting their guidance from.

On 7/26/2016 1:52 PM, Eoin Hamdam wrote:
> I have had Virtualised DCs on the same hosts as Exchange VMs for ages
> and never came across that as being an issue either.


michael1 posted this 26 July 2016

Way back in the day, when memory was expensive and so were megacycles per user, there was a recommendation of 1:4 (AD:Exchange) cores. And at that point, everything was physical. Today, I think the recommendation

is 1:8 (assuming your DIT fits in RAM) and nobody cares virtual vs. physical. The EXCHANGE recommendation is 1:1 phys:virt cores, but not more than 1:2 on cores. However, 1:1 phys:virt memory is the only configuration supported.


Like Brian says – simple capacity planning. Both AD and Exchange scale well. Exchange isn’t horribly happy about oversubscription because it does its own memory management and processor management.




g4ugm posted this 26 July 2016

Actually Active Directory can also be a memory hog. It will try and load the database into RAM if possible...



g4ugm posted this 26 July 2016

Having read some papers I note that VMWare say to leave Hyperthreading enabled, BUT to make sure you only count Physical when Capacity Planning Dave 


sbradcpa posted this 26 July 2016

'course he is posting from .edu and I'm a lowly SMBer so I should just
shut up. :-)

I'm just saying that I've never seen a 1 to 1 processor requirement in
virtualization and we virtualize a lot of stuff down here and have
always gone with the guidance Especially in the newer OS's that are
built in the virtualization era.

On 7/26/2016 2:57 PM, Dave Wade wrote:
> Actually Active Directory can also be a memory hog. It will try and load the database into RAM if possible...
> Dave


g4ugm posted this 27 July 2016

Having worked in both corporate and University environments, the "business requirements" can be very different...



patrickg posted this 27 July 2016

It really all depends on your workload. For a consultant saying 1:1 means they don’t need to know anything and you’ll never have CPU congestion. I’ve run DC’s on VM

farms in densities (HT enabled but excluded for the counts) of up to 30:1 before without any issues. While the 30:1 was an extreme large number of VM’s sitting idle 99% of the time, you can get that kind of density depending on the workload. In the current

Prod farm we are running DCs/Exchange/Oracle/SQL/Sec cams/Solarwinds/IIS/you name it and running at a more reasonable 2.9:1 under VMware. Given this environment, I know I can’t go above 3.1:1 else there will be ready-wait issues.


Under VMware the general rule of thumb I’ve always gone by for mixed workloads has been start with 2:1, check the ready wait and see. If it looks clean, put a node into

maintenance and up the ratio until you see congestion. Once you do, you’ll know what you can’t go above. The only exception to this are say you have 14 cores and carve out a 12 vCPU VM…you won’t get very far on densities like this.


With any Hypervisor the CPU/Ram/Storage is a shared resource and while VM’s do require a certain about of dedicated CPU resources, it’s really a dedicated amount for

a given clock-cycle. VM’s only use what they need and sit idle the rest of the time.





BrianB posted this 28 July 2016

Thank you everyone for your responses. I believe that we have been able to present enough information based upon your responses to keep from stirring up a grief about dedicating hardware unnecessarily.

Thank you again.

Brian Britt