This is the first part in a series of three articles describing how I created a basic DNS/DHCP/NTP server for my lab that only uses 24MB RAM and 12MB disk space.
I’ve been building a new lab environment recently and wanted a small infrastructure server that could sit permanently in the management cluster and provide basic services such as DNS, DHCP and NTP. The lab will host multiple different testing environments, often for short periods of time. I use the ever awesome Autolab to rapidly provision new setups. Autolabs are self-contained, so they provide their own Active Directory (AD) domain controller (DC), which in turn includes DNS/DHCP/NTP, along with their own vCenter and nested hosts. But to save a considerable amount of rework after I’m finished with each test environment, a management cluster will provide the base services I need and can remain in-place through each cycle. Chris Wahl has a lengthier post espousing the benefits of such a strategy.
Why vCSA instead of a windows-based vCenter?
- They both use similar amount of resources – you can happily run it on 3GB vRAM for a small lab
- Autolabs use a windows-based vCenter, so I still gets lots of face-time with them
- vCSA is more stable in my opinion
- vCSA only takes a few minutes to deploy and is simple to update/patch
- vCSA doesn’t need a Windows license. This is a deal breaker for me. I don’t want to rebuild my management vCenter every 180 days (technet is going away)
So what else do I need in the management cluster? AD? I thought carefully about this because of the 180 day license timeout. And honestly, for the small amount of servers it simple isn’t worth it. Nothing in my management cluster needs AD, so why bother.
So without a DC I also lose other basic services that we take for granted, such as DNS, DHCP and NTP. In reality I could do without those as well. I don’t need DNS if I’m happy to use IP addresses everywhere in the management cluster. I expect most long term components will have static IPs so there’s no strict need for DHCP. It’s a lab so is time that important? (actually it can be, and it becomes particularly obvious in a more volatile physical/virtual lab environment). So perhaps I could do it all with just one vCSA and the physical hosts in my management cluster.
But I thought it would be handy to provide these simple services as I plan to spin up a number of associated management tools such as backup, monitoring, logging, etc. I know before long I’ll have a non-trivial number of long-term appliances that would benefit from these services. We live in the world of bespoke virtual appliances I thought – it shouldn’t be that hard to find a good solution just designed for this purpose. Surprisingly, there wasn’t an obvious contender.
Which tool to use?
I reviewed a number of options:
pfsense came highly recommended:
pfsense is small firewall appliance that comes bundled with lots of additional features. It only uses 128MB of vRAM so is sufficiently small for a lab and it has a nice web interface. Unfortunately I wrangled with it for hours and never got it to work properly. I kept putting it back on the shelf, looking at alternatives, picking it back up again; would get frustrated with it, and went back out to find something else. I’m sure it’s a great package, but it evidently wasn’t for me.
I was somewhat familiar with FreeSCO as it’s the “router on a floppy” VM that Autolab uses as its gateway device. It ticks a lot of boxes and runs comfortably in only 16MB of vRAM. It’s not the most handsome web interface but configuring it is relatively straightforward. However the functionality of the server services that I was looking to host were more limited on FreeSCO than the competition.
OpenWRT includes the dnsmasq package to provide basic DNS and DHCP functionality. This is a common toolkit and would satisfy my lab needs. (You can replace it with a BIND configuration should you wish a richer DNS option. OpenWRT packaging is handled by okpg which is very similar to dkpg so anyone familiar with Debian/Ubuntu should feel right at home.)
I’ve often thought about getting one of these Rapberry Pi devices, but could never come up with a good use-case (Xtravirt’s vPi looks interesting but I’m not convinced that it would be anything more than a toy for me). I then thought about the pfsense, FreeSCO and OpenWRT appliances I’d been testing. After some digging it seems that there is some preliminary support for OpenWRT on the Raspberry Pi. I thought how useful it could be to have a virtual copy on the first lab host that could travel with the lab (the Intel NUC hosts are very portable so they make an excellent mobile lab), and a small hardware appliance with a similar configuration (and no vSphere dependencies) when everything is static and ticking along. Very small footprint, low power, and plenty of geek cred!
The next post will explain how I installed OpenWRT into a VM and configured the networking for multiple VLANs.
- Detoks on vSphere 5 Card
- Forbes Guthrie on vSphere 5 Card
- Namma Karma on vSphere 5 Card
- Micro infrastructure server with OpenWRT – part 3 | vReference on Micro infrastructure server with OpenWRT – part 1
- Micro infrastructure server with OpenWRT – part 1 | vReference on Micro infrastructure server with OpenWRT – part 2
- Forbes Guthrie on Large Pages – a problem of perception and measurement
- Eduardo Aguiar on Large Pages – a problem of perception and measurement
- Forbes Guthrie on How to PXE boot from your trunked vmnic0
- Bryan on How to PXE boot from your trunked vmnic0
- AlphenIT on vSphere 5 Card