Opinion on Virtual Server

[Genx87]

I have just started playing around with VMWare free virtual server and will try out Microsofts beta soon.

The question I have is, do you think it is a good practice to stick your primary AD + NAS on the say machine? I am debating if we should bring in seperate machines for a NAS and new AD or if we can stick them on same machine.

The biggest issue with doing this for me is the fact if the hardware craps, we lose two operating systems. Yes I have a diaster recovery plan ready and waiting on my backup AD controller.

But am I making too big an effort to consolidate in such a small envrionment?

Currently I have 1 2000 SBS, 2x 2003 servers. If I went the VM route the 2000 SBS goes away and is replaced by a virtualized 2003 SBS, running on top of a 2003 storage server.

If I dont, then the 2000 sbs goes away and is replaced with a 2003 SBS machine + 2003 storage server machine.

So I go from 3 to 4 servers.

Current setup is the 2000 SBS server is the pri ad, print, wins, dns, file server. So from the standpoint of reduced reliability it isnt different. Currently if the hardware conks I lose the same as I would if I went the VM route.

I am curious what you guys think.

 

[RebateMonger]

I have NOT done any production Server virtualization yet. But I've attended some recent lectures given by people who have done Virtual Server in small-business environments.

Many people are NOT big on the idea of virtualizing SBS 2003. Especially because it's running Exchange and, possibly, SQL Server. Those aren't especially good candidates for virtualization. In fact. I've only found ONE person who has done it.

Similarly, many don't see virtualized servers as good places to put heavy-duty file operations. Virtualized disks are going to be slower than "real" disks.

I think that minimizing the number of servers is a great goal. Every time you add a hardware server, you increase hardware failures. But SBS already has a LOT of functions onboard that are often relegated to separate servers in larger companies. So, effectively, you've already done a lot of server consolidation.

 

[Nothinman]

The biggest issue with doing this for me is the fact if the hardware craps, we lose two operating systems.

But the VMs can be brought up on any hardware without any issues since it's all virtualized, just restore your backups of the VM disks to a new box and power them up. And the same goes for migration, if you need beefier boxes you just buy them and copy the VMs and adjust their memory, etc.

I don't know about putting the AD in a VM, if the OS hosting the VM is a member of that AD it might not work too well. But otherwise it shouldn't be a problem.

Similarly, many don't see virtualized servers as good places to put heavy-duty file operations. Virtualized disks are going to be slower than "real" disks.

You can always give VMWare raw disks.

The only thing I would say is that I was very disappointed with VMWare's performance on a Windows host. Running just 1 VM on my XP workstation caused the whole thing to hit the disk a lot more than it should have, VMWare on Linux runs a ton better.

 

[Rilex]

As for using DCs in VMs, as long as the host is also a DC (or you have another physical DC), it shouldn't be a problem. Otherwise you'll have to deal with slow startups/logons.

You can certainly use RAW disks in VS/VMWare, but that is kind of a disadvantage IMO. It leads to less portable VMs and less VMs per physical disk.

Exchange 2003 IS supported in Virtual Server. I don't know about SQL 2000/2005. ISA Server is not supported in VM (though honestly, I had it working just fine).

With VS, not sure about VMWare, make sure the physical server has at least two NICs. One for the physical server, and the other dedicated for the VMs. The NIC that has the VMs needs all offloading capabilities turned off -- this can cause file copies via SMB/CIFS to fail depending on the size.

 

[Nothinman]

You can certainly use RAW disks in VS/VMWare, but that is kind of a disadvantage IMO. It leads to less portable VMs and less VMs per physical disk.

Portability is still there if you use fiber disks or you hot-swappable disks. But you'd probably only want to use RAW disks in extreme circumstances anyway.

With VS, not sure about VMWare, make sure the physical server has at least two NICs. One for the physical server, and the other dedicated for the VMs. The NIC that has the VMs needs all offloading capabilities turned off -- this can cause file copies via SMB/CIFS to fail depending on the size.

I vaguely remember something similar to that but I thought it was only one way, meaning you only had to turn off Rx or TX but not both. But I could be way off base since it's a hazy memory. And you'd probably want one NIC per VM anyway just for normal performance reasons, depending on what the VM's job is of course.

 

[ktwebb]

As long as you have gigabit NIC's then typically you won't run into bottleneck issues with VM's. Clearly mileage will vary. We have around 80 ESX production VM's running on a 4 port GigE switch module in the bladecenter. About 35 running on a single GigE interface in test/dev. Many of the VM's have relatively high bandwidth considerations. Never had a problem with throughput. Obviously each environment will have different requirements but dedicating a NIC to each VM may not be practical. It definitely would not be for us.

As for the OP's questions. CLuster your hosts if your really worried about fault tolerance but as mentioned, these are disk files. Should be easy to get back up and running with little effort, or the Virtual environment isn't engineered very well.

 

[stash]

Virtualized DCs are supported, but certain configurations are not recommended. For instanced, FSMO holders, GCs that service Exchange servers and bridgeheads should not be virtualized.

There are three supported scenarios with virtualized DCs:
* domain controller running in a virtual machine on a guest OS with applications services running on the host
* domain controller running on the host with application services running in a virtual machine.
* domain controllers and applications running in separate VMs, with nothing running on the host.

http://www.microsoft.com/downloads/deta...-4209-8ED2-E261A117FC6B&displaylang=en

Microsoft's support policy for third-party virtualization software can be found here: http://www.support.microsoft.com/kb/897615

 

[RebateMonger]

Originally posted by: stash
Microsoft's support policy for third-party virtualization software can be found here: http://www.support.microsoft.com/kb/897615

Hehe...I expected to find a blank KB article. It ALMOST is, but at least it's there.

 

[Genx87]

Thanks guys for the input. I will go with seperate machines as it doesnt appear virtualizing primary DCs is a good idea.

 

[RebateMonger]

Originally posted by: Genx87
Thanks guys for the input. I will go with seperate machines as it doesnt appear virtualizing primary DCs is a good idea.

I think we are going to see a lot of virtualized DCs.

The main points of the Microsoft article quoted by Stash are:
1) You have to be careful not to accidentally run two identical DCs on the same network
2) A REALLY busy domain may need a fast-responding DC, especially for Exchange.

But you always have to know what you are doing to play with DCs, and many organizations don't have terribly busy Exchange Servers. My earlier warning about disk responsiveness for Exchange and other disk-intensive operations can be fixed by using a non-virtualized hard drive for your file stores and Exchange data stores.