Allan Anderson's questions

We have a small server farm (11 now, may add more in the future) of HP Proliant DL160 G6s. They all run either Linux (server only, no X11) or VMware ESX. We had intended to get models with iLO, in case BIOS-level remote admin became an issue, but that didn't happen.

I had an IP KVM switch recommended to me (along with some sort of Remote Reboot hardware.) I've since realized that none of our machines need GUI administration, so perhaps a serial console switch would be a cheaper and more appropriate option. Something like this: http://www.kvm-switches-online.com/serimux-cs-32.html

Do you folks have an opinion on which way is a better choice? Should we go for the ease of setup (plug and go, instead of turning on the feature in the BIOS and making sure the serial settings are correct) and the flexibility of an IP KVM switch even with the extra cost? Or is a serial console switch just fine?

We are setting up an 8-machine build farm. Most of these builds need to happen on a specific flavor of Linux (Fedora 10 as of now), while some of them will happen on several different Windows VMs. We were considering using Eucalyptus or the Ubuntu Enterprise Cloud to run the Linux VMs, and just have VMWare on a couple of machines dedicated to Windows builds when we need them. However, it seems that OpenNebula would work in a similar fashion, but allow us to have some or all of our nodes running VMware's free (as in beer) ESXi.

So my questions are:

1. What do you folks see at the big differences between Eucalyptus and OpenNebula?
2. Are there strong reasons to prefer one hypervisor over another? How about VM format? (is KVM easier to use with Fedora, for instance?) Windows support makes ESXi the most likely choice, but I'm wondering if there are any gotchas.
3. Does any one system's administration and monitoring make it preferable to the others? We'd likely control them mostly through script interfaces used by our build tool.

Thanks!

We've got a Linux-based build system in which a build consists of many different embedded targets (with correspondingly different drivers and featuresets enabled), each one built with another single main source tree.

Rather than try to convert our make-based system to something more multiprocess-friendly, we want to just find the best way to fire off builds for all of these targets simultaneously. What I'm not sure about is how to get the best performance.

I've considered the following possible solutions:

• Lots of individual build machines. Downsides: lots of copies of the shared code, or working from a (slow) shared drive. More systems to maintain.
• A smaller number of multiprocessor machines (dual quadcores, perhaps), with fast striped RAID local storage. Downsides: I'm unsure of how it will scale. It seems that the volume would be the bottleneck, but I don't know how well Linux handles SMP these days.
• A similar SMP machine, but with a hypervisor or Solaris 10 running VMware. Is this silly, or would it provide some scheduling benefits? Downsides: Doesn't address the storage bottleneck issue.

I intend to just sit down and experiment with these possibilities, but I wanted to check to see if I've missed anything. Thanks!