I need to learn a lot more about the guts of Windows server.

My current knowledge consists of what I picked up from our former corporate IT guys and from what limited access I have to our local servers at work. For some reason they don't want me poking around in AD at work.

So, the plan is to build a server at home where I can break it as much as I want without upsetting anyone.

Since we are setting up some virtualized servers here, I figure I need to look into this at some point as well.

Since this server will not be under much load, I should be able to get away with a desktop CPU, but how much CPU and memory do I really need.

I also don't know that I really need raid 5 capability.

So, any suggestions from the server guru's here would be appreciated.

Depends whether you're doing virtualization or not. Add virtualization in, and suddenly you need a lot more CPU and a TON more RAM. I don't think you need RAID to play with at home.

I figured virtualization would up the requirements.

Are more cores better in this scenario? I was thinking of an AMD Phenom II X6.

If you're only virtualizing one server on that home computer, then you don't need much more RAM or CPU than an equivalent physical server would require. The biggest issue is that the system that runs the virtual machines itself requires CPU and RAM. The least resource-intensive solution is probably something like the free VMware vSphere Hypervisor.

This product gets installed on the physical computer, you then interact with it via an admin console which helps you get VMs running on it.

The plan is to learn in two stages. The first is to understand AD better, and to get my feet wet setting up a DC, WSUS and the like.

The second stage would be to set up a second virtualized server to understand trust relationships between servers and to understand how DC replication works. Understanding virtualization along the way is an added bonus.

If you are virtualizing you will need two computers. The one running the hypervisor can not be interacted with directly. The one running the management software doesn't really have to have much power though. So any machine you have laying around will do.

Maybe even one of these.


Sorry.

Hmm, blocked. It must be kitty porn.

Chris, I presume I can run the console on one of the computers on the network?

Aaaabsolutely!

Yeah. It has to be able to reach the hypervisor over the network. So either local, or the hv can be listening on an outside IP.

You can run the management software on a machine running under the hypervisor, and RDP into it. But that's not really recommended.

Sure it is. You'll just have a hard time BUILDING it without a separate box for management.

Or troubleshooting when something breaks.

pshaw, what EVER breaks with ESXi?

Kitty porn, huh? Well, you asked for it.

Nice pus*y.



Sorry.

Pussy is a perfectly acceptable word. I know this because it's in a nursery rhyme book I used to read to my kids. It goes like this:

I love little pussy.
Her coat is so warm
And if I don't hurt her
She'll do me no harm.

Perfectly tame and non-double-entendre-able. Right?

Peter, you're going to have messed up kids!

OK, I did some poking around and it looks like a Phenom II X6 will be just fine. It seems VMware is persnickety about mobos though. Mostly issues with NICs and SATA controllers.

I see that ESXi 4.1 supports hardware fault tolerance. At work we are paying $$$ for a Marathon solution to get both hardware fault tolerance and virtualization.

So, what would you guys consider a minimum requirement for RAM?

8 gig should do well to start. Get the biggest sticks you can, so you have room to add more later (i.e. don't get 8x 1GB sticks and fill up the board). I'm guessing you're looking at a single CPU board? If you're going with dual CPUs, you will need an equal amount of RAM local to each.

I don't know if you get fault tolerance in the free ESXi package.

Depending on how you setup your disk (ie multiple spindles or SSD) you could put a LOT of virtual machines all on the same physical box. The CPU itself doesn't matter too much although I'd recommend picking something with 4 cores (not HT). The machine would easily run at least 4 VMs. That way you could have 2 DCs to practice setting up a site plus another running WSUS. Most "desktop" motherboards these days can go up to 16G of ram. Since you're just using this as a learning tool you could prob get away with using 1-2G of ram per virtual server. I will emphasize all these recommendations are for a box that performance and reliability are not the most important requirements.

If you are truly "green" you might way to consider first just installing Server 2008 R2 Standard and enabling HyperV on it. That way you can get familar with the concepts of virtualization with the luxuries of doing it all on a windows machine (managing hdds for instance would be much easier). When you are ready to get into more advanced virtualization you could put ESX, XenServer or HyperV server on the physical machine.

I wouldn't wish HyperV on my worst enemy. XenServer unfriendly, and unpolished. It's true ESXi is powerful, but it's also pretty darn easy (as these things go) for a simple setup.

No way. FT requires a) multiple servers and b) vCenter. Which requires a full bore vSphere license (I think starting at Advanced?)

But INANE is right, the true bottleneck in virtualization is (and probably always will be) storage speed.

At work I'm running about 60 guests across 3 hosts (with RAM and CPU free, I could probably push things up to 90 guests, but really want to upgrade the hosts to dual Six Cores and 64 GB of RAM). Each host has dual Quad Core CPUs, with 32 GB of RAM. The storage is provided over iSCSI (two bonded 1Gb links) by a 24-drive array, organized into three arrays of 8 drives each under RAID6. Each individual drive is 1 TB, so with RAID6 that's 6 TB, or a total of 18 TB (which is way more than enough, because if you have a machine that's trying to eat up disk space as quickly as it can, it's not a good candidate for virtualization).

Once everything is up and running performance is very good. But a cold boot is painful (taking about an hour), even serializing the the loading process still causes so much disk contention that the arrays are saturated for a good while. (We have plenty of battery backup, and a generator, so cold boots are extremely rare).

In contrast, our setup at work will run... one virtual environment to start. Really its stupid. The application they are putting on this machine could run on any old desktop. It is not time critical, so as long as we have a backup machine and backup the db the app uses, we would be fine.

My boss' plan (as opposed to the corporate dudes) is to move our production DBs off our aging AS/400s to the new vm machine, the intent being to provide both harware and software redundancy. We have one other critical app that would also benefit from this sort of setup.

At home my demands are much simpler.

By cold boot, do you mean starting up the three hosts and all their vms? If so, surely staggering the boots a bit could help you cut that time down by reducing contention.

Yeah, from full power off.

I've only tried it a few different ways. But the delay until VMware Tools is loaded (still a little overlap as the machine that just loaded the tools settles down), seems to be the fastest. Fixed delays either have too much contention if set short, or a lull between loads if the delay is set too long. I have the important machines loading in order of importance. Then the workstations coming up in random order.

Really if you think about it, 60 minutes for 60 machines to boot is only 1 minute a machine (it's probably more like 3 minutes per machine with 3 loading at the same time). I don't expect it to be much faster, but still I dread shutting it down, because I know it'll be at least an hour before my phone finally stops ringing.

Yow. Yeah, I discovered the other day that cold booting my single server VMware View installation with ~20 desktop VMs and a single (at the time) local datastore produced... less than ideal results. I've never seen kernel latency so high. I'm hoping to get shared storage and at least a second, if not a third, server up there very soon. Just need to finish decommissioning my current vSphere setup.

Why are you guys running multiple desktops on one server?

Because then you can maintain them all as one, among other advantages. Basically, you can link many desktop vms to a single master image. Need to do some system updates on all your virtual desktops? No problem! Just update your master image.

Another major advantage this provides is portability. You can connect to your desktop vm from anywhere.

This kind of solution really makes a lot of sense for many companies.

Well, we're not doing the first part. But the second is the important bit. Also, disaster recovery for the future--if you can migrate all of your desktop VMs to a remote site, bing, people can be up and running (at least on their desktops) almost immediately.

Connect with what and to do what? Are the VMs replacing desktops?

We're using VMware View. Around the office we have Wyse P20 thin clients. But there is also a client for Windows/Mac/Linux that allows anyone with a computer to connect to the View connection server and access the same computer that they see at their desk. They can even sit down at someone else's desk and still get the same computer they have at their own.

Fred, essentially yes. This only works in certain scenarios, because obviously you have to have SOMETHING to connect to the VM with. It works well for test/dev stuff, or for work from home type situations.

OK, that makes sense. I thought I was having flashbacks to dumb terminal days (or do they call them ultra-thin clients these days??).

Zero clients, if you believe that.

Everything old is new again.

For the record I liked serial terminals, and am all for keeping computing resources localized, and just having displays out on the desk.

Hmm, what does that make the user, a zero?

Its funny how things just keep cycling.

Doesn't running a whole whack of desktop VMs clog the network? We can't seem to keep things reasonable between here and our head office and we do not exactly have high bandwidth demands.

Not really. They use RDP or PCoIP, both of which are pretty lightweight protocols. I get decent performance at home going from my crappy 1.5mbit DSL connection across the country to HQ.

ICA (XenApp & XenDesktop) >>>>>>>> RDP or PCoIP

So much to learn...

Does anyone have a link to a recent good overview article on Virtualization? I found a 2009 Infoworld 'Deep Dive' article, but at this point it is 2 years out of date.

I am trying to understand the technical differences between some of the differing approaches. For instance, the Marathon solution we are implementing somehow sits on top of or modified the windows server OS, but that does not make sense to me.

You could check out these articles. I haven't read them, but Ars Technica is usually pretty good.
They're VMware focused, so they probably won't talk about Marathon.

Thanks Ken, I'll give them a look.

Marathon looks like a closed shop. Their 'white papers' are marketing fluff and there is nothing resembling useful technical info on their site that I can find. It looks like they are attempting to generate a significant portion of their revenues from 'consulting' as in holding useful info back and selling it in the form of services.

I can't say I've ever heard of them, but I'm pretty much a VMware guy.

I've not heard of Marathon either. I ended up being a VMware guy after reviewing the big three, HyperV and Xen being the other two.

IMO for just setting up a test environment at home it doesn't matter what you use. Bare metal or something sitting on top of windows (virtual box works well for that).

If you are interested in actually learning about the major players in virtualization that's a different story. I just thought the original intent was to setup a lab at home to test out some software and AD.

Best advise I could give is to pick one thing to learn and focus on that first (virtualization or the other software products). It's not like rebuilding the test setup over and over would be a bad thing (likely be a very good thing actually).

Good points all around.