Should DC, AD, DNS, DHCP servers be in VMware env?

Should DC, AD, DNS, DHCP servers be in VMware env?

Hi everyone,

Although recovery time for PS (Physical Server) is ridiculously long  compared to that of VM, we currently cannot convince people to  virtualize these types of servers. The argument was the fact that if  something goes wrong -- long after the servers are virtualized -- we  must reproduce the problem in PS before the vendor would even consider  troubleshooting it.

Q1: Have anyone out there had ESX hosted these types of servers? What are the keys to make this happened?

Q2: Generally, if someone says "my vendor said that application is not supported in VMware" what should the approach be?

Q3: Is there a tool to convert back to PS ... like V2P?

Thanks!

PS: If this is the wrong discussion group, please point out the proper one.


A1:We host an old NT4 PDC in a VM - it actually performs much better.  Basically it went there because the physical server was old and failing.

Many people run those servers in VMs, depends on the size of environment in my mind.

A2: DC, AD, DNS, DHCP are all microsoft (Im assuming) and if you have  premier support they will support it in a virtual environment. Other  apps its pretty much SoL, Ive ran into a few vendors that say that and  its mostly just laziness on thier part to test thier apps.

A3: there are a few tools that do that, powerconvert from platespin does, HP also has an offering.


Every vendor has a different VMware support policy. Almost all vendors  support it in some fashion. Microsoft is stubborn because they have a  competing virtualiztion product. They will make best effort to support  there product on Vmware and only ask to reproduce the problem on a  physical system if they suspect it is related to the VMware enviroment  (which it usually isn't). If you have premier support with them I  beleive they will not ask you to do this. I have half my DC's  virtualized, that way if there is a domain problem I have physical one's  also. In the planning phase of my virtualization project I researched  Vmware support statements from each vendor that was going to be  virtualized. If the vendor says they do not support Vmware, ask them  why. Alot of times it's because they have never taken the time to try  their product on Vmware. In 99% of the cases it will run just fine on  Vmware. You can test it and see, put your dev/tests systems on Vmware  and if they are fine after several months then migrate your production  systems.

Virtual Machine to Physical Machine - Migrationhttp://www.vmware.com/support/v2p/doc/V2P_TechNote.pdf
Microsoft Virtual Machine Technology FAQ - http://www.microsoft.com/licensing/highlights/virtualization/faq.mspx
Virutalization of Active Directory - http://www.vmware.com/community/thread.jspa?messageID=352424&#352424
Considerations when hosting Active Directory domain controller in virtual hosting environments - http://support.microsoft.com/kb/888794
Virtualizing a Windows Active Directory Domain Infrastructure - http://download3.vmware.com/vmworld/2006/tac9710.pdf

fyi...if you find this post helpful, please award points using the Helpful/Correct buttons...thanks


I would never put your FSMO and primary DFS and GPO host in Virtual,  just due to pure performance and instantaneous needs, but any secondary /  periphery systems you might have should be fine as VM's, no special  circumstances \_need_ to be considered as far as I can tell.  None of  them do anything funky with the network, all normal TCP/IP traffic.

Be aware of the growth of the DS in terms of disk size so you don't have to worry about taking DC down to expand the disk, etc.

It might be a good idea to put reservations on the resources for the VM's, just so their instantaneous needs can be better met.

If a vendor says they won't support the application in VM, just make  them aware that if they don't, their product will fall by the wayside as  others fill that market - but say it in the nicest way possible Smiley Happy


Why would you never put FSMO roles on VM'S? Schema Master, Domain Naming  Master,  RID Master and Infrastructure Master are not that resource  intensive or used on a constant basis. PDC Emulator is the only role  that I could see being utilized frequently. You can also make multiple  DC's Global Catalog servers to serve as backups to each other.


Yah sorry, I started thinking our environment and our "DC01" is the big honco, PDC Emulator, everything etc.


Q1: Yes / Why to you run other servers as VMs? \[Put your reason here]
Q2: Some vendors are not (yet) familiar with vitualization. Try to show  them the benefits and do a pilot with them to show them that it simply  works. Try to get them into your boat. That usually works. - If that  doesn't help it's always good to inform that vendor the other  concurrence vendor supports virtualization ... Smiley Wink
Q3: PlateSpin and others do that. Here's the official VMware point: http://www.vmware.com/support/v2p/


As said in this thread already all of these microsoft services virtualise with very little difficulties .

IF you're having a problem selling it, for me you need only look at the advantages that Vi3 provides;

HA: High Availability, abstraction from hardware failures
DRS: Resource Scheduling to ensure VM performance across the cluster
VCB: LAN free backups...

What type of issues do you get with the physical servers, would  virtulisation be increasing these or adding value to the service  delivery.


Q1: Have anyone out there had ESX hosted these types
of servers? What are the keys to make this happened?Yep, we host pretty  much entire back office infrastructure on ESX today. That includes  \*ALL* domain services, DHCP, network management suite, backup  infrastructure, all exchange services except mailbox servers  (bridgeheads, antispam, BES, etc), SQL, Oracle, etc... I could go on Smiley Happy The key to making it happen in our case was buy-in from the top of  our organization that this was the right approach. Once that happened,  everybody else sort of fell in line..

Q2: Generally, if someone says "my vendor said that
application is not supported in VMware" what should
the approach be?Generally, the way I see it, is that a software vendor  should be hardware agnostic. With that said, many still will play the  card of "we'll provide commercially viable means to help troubleshoot,  buuut.. we may ask you to convert back to a physical server". I'm  actually in the middle of a project where I keep hearing that, and I  keep asking the same question of these vendors (I phrase it one of the  following two ways):


\- "Other than being potentially faulty, something that is minimized  when talking about virtual machines, what does the type of hardware that  your application runs on have anything to do with if it's functional?"

\- "What does the hardware have to do with anything? Aren't we talking  about software here? Shouldn't the operating system, and it's various  patch levels, have more to do with issues?"

I see this "lack of support for virtualization" to be a ploy by software  manufacturers to not have to support a new platform, but the irony of  it is that in a lot of cases, these products are being developed and  tested internally on some virtualized platform... It's funny how things  work, huh? Smiley Happy


Hi everyone,

Although recovery time for PS (Physical Server) is
ridiculously long compared to that of VM, we
currently cannot convince people to virtualize these
types of servers. The argument was the fact that if
something goes wrong -- long after the servers are
virtualized -- we must reproduce the problem in PS
before the vendor would even consider troubleshooting
it.

Q1: Have anyone out there had ESX hosted these types
of servers? What are the keys to make this happened?A LOT of people have  their DCs virtualized. DNS and DHCP is even more trivially virtualized.

Q2: Generally, if someone says "my vendor said that
application is not supported in VMware" what should
the approach be?It depends on the application--there are things that  don't virtualize very well, and the vendor may have a legitimate reason  (like ESX doesn't support hardware that their application talks to etc.)


Then again the vendor may be back in the horse and buggy days, in which  case you should assist the market in selecting them out.

Seriously. Other than applications that need SERIOUS hight performance,  or are oddly hardware dependent you have to have written your product  fairly badly not to work inside a VM.

(For example it doesn't make a lot of sense to deploy a Bewoulf Cluster  on ESX, nor would it make a lot of sense to deploy a Real Time OS that  controls CNC machinery etc.)

Q3: Is there a tool to convert back to PS ... like
V2P?You could do it with Ghost or Alteris like tools, if you have the right drivers already installed or available.


A couple other thoughts.

Often people have these services running on old servers, 3-5+ year old  servers, and to me the risk of staying on these old servers is higher  than moving to a VM. Old servers are more likely to have hardware  failures.

Since there is more than one (DC, DNS, DHCP, etc) server, start by  virtualizing one of each. We have had several DCs, secondary DNS, DHCP,  and WINS all running in VMs for a year now. Everyone is now comfortable  with moving the rest of this infrastructure to VMs.

Most first level support you deal with wont ask, or even know your  application is running in a VM, don't offer that up either IMO. Also,  reproducing on physical hardware should be the last step, after all  other possibilities are examined. My personal favorite P2V and V2P tool  would be PlateSpin PowerConvert, with this you can basically go any  direction.


Most of ISVs says that they not certificate their applications if they  run on VMs, but the fact is that the applications talk only with the OS  and not with the Hardware (HW).  VMware Virtualizes the HW, but for  applications it really don't matter.  Then, if your OS is certified for  VMware you should have no problems for support.

Now, talking about your question, this services may run on VMs without  problems, except DNS, because ESX and VirtualCenter use DNS for name  resolution.  If you want, you can configure hosts file for name  resolution to workaround this problem, but if you use VMware HA, you  need DNS. Then you can configure a DNS on a physical server and leave  all your other services (include alternate DNSs) in VMs

SLT


We host multipes of these for several companies.
12 DC's for 6 different domains 10 ar AD
DNS for 2 companies
DHCP services for 3 companies.

As far as AD/DC how many users and queries would be the concern
These servers support 600 people total no issues, including vpn, and pt to pt tunnels

Q2 do not tell them it is a vm, until the request logs and see for themselves what the hardware is. Most
of vendors do not recommend specific hardware.

Q3  I ha succesfully used Bart PE to V2P several systems and 1 stayed as physcial due to the high utilization


Q1: Yes / Why to you run other servers as VMs? [Put
your reason here]

Oh I have tons of reasons. What I dont have is a selling skill... I'm  tiny technical guy and MS reps are pretty big and heavy ;-(

Q2: Some vendors are not (yet) familiar with
vitualization. Try to show them the benefits and do a
pilot with them to show them that it simply works.
Try to get them into your boat. That usually works. -
If that doesn't help it's always good to inform that
vendor the other concurrence vendor supports
virtualization ... Smiley Wink
Q3: PlateSpin and others do that. Here's the official
VMware point: http://www.vmware.com/support/v2p/-----

I am running DHCP, WINS and Radius on virtual servers running Windows  2003 on ESX 3.5 with VC 2.5. Not a single problem what so ever. Both of  the dhcp servers were cloned using VMware convertor enterprise (Cold  Clone). I also resized the hard disk since it was a waste to store 75GB  for my dhcp server on my precious SAN storage Smiley Happy.


Hi,

We are in the process of virtulizaing our entier MS Infrastructure from  P.S to Virtual enviroment in upgrading the exisiting exchange 5.5 to  exchange 2007. both the esx hosts will be in cluster mode and accessing  HP MSA 1000 SAN in active/active. IN DR-Site, there will be the same  setup with DL380 in cluster mode and also there will be an HP MSA 1000  in active/active mode, and the SAN merroring will be replicated from  Primary Site to the DR Site.


This document was generated from the following thread: Should DC, AD, DNS, DHCP servers be in VMware env?

Comments

Q1: Yes / Why to you run other servers as VMs?

Q2: Some vendors are not (yet) familiar with vitualization. Try to show them the benefits and do a pilot with them to show them that it simply works. Try to get them into your boat. That usually works. - If that doesn't help it's always good to inform that vendor the other concurrence vendor supports virtualization ... Smiley Wink

[I agree entirely with you. In the Middle East, specially Bahrain, when I wanted to start the Virtualization with my Email and Domain Project, we have called a Vendor imagine what the sales representative said about the Virtualization, he said VMware now is going to lose their market value as other competitor's already in the Virtulization World, specially MS and Xen. Why he said that? Because, if we are going to start this project we are going to cut the cost around 47% from the proposal which they have given on physical servers. Just the sales representative he doesn't want to lose some $$ by going to the Virtualization and cut the cost he said the VMware going to lose their market value Smiley Happy .. In my opinion, VMware has to educate their Sales Representives around the world Technically and in the Solution wise which the suppose to provide to their customers.

Imagine, because of what he said to our management, our management they have canceled to go with Virtualization in the Production network. So, can I say this guy has made a poor reputation about VMware Products? If not, then what is the reason behind that?]

Q3: PlateSpin and others do that. Here's the official VMware point: http://www.vmware.com/support/v2p/

Best Regards,

Hussain Al Sayed

Version history
Revision #:
1 of 1
Last update:
‎10-21-2008 07:13 AM
Updated by: