Also posted on Simon Seagrave’s Techhead.co.
Razor is a cool new deployment tool for your entire server infrastructure. It’s has been and is still being developed as a joint venture between EMC and Puppetlabs (who also make the amazing open source application automation tool Puppet), with the constant influx of code from other open source aficionados as well. For those interested in what, why and how Razor can be used I’d gladly point your here: what, why and how.
During the last two months I’ve been spending a lot of time on lab sessions, blog writing and vacation. The labs with Razor has been a lot of fun, but they’ve so far been contained in a VMware Workstation environment. At our new shiny office in Stockholm, we’ve recently upgraded our demo center and are waiting to get tons of new cool hardware, so I thought I’d try out how Razor would work for me for real in my home lab before doing the ESXi deployments at work. I followed @lamw‘s great blog post on how to deploy ESXi with Puppet and Razor, and I’d suggest you read it too if you haven’t already. I have two HP MicroServers that the always-so-nice Simon Seagrave helped me aquire a year ago, and booted them up.
Unfortunately I quickly ran into a snag, as it wouldn’t properly start the Razor image when PXE-booting. What happened was that the NICs in the MicroServers use something called the UNDI API, and therefore would lock up during boot as some of the Razor settings were not properly applied. After some searching on support forums and GitHub tickets, I finally found a working solution and I’d like to share it with you all.
Word of advice, Razor is still in beta, and things can change later when new versions are released.
The setup I’ve been using consists of one Ubuntu 12.04 server, dnsmasq for DHCP and DNS, tftpd-hpa for TFTP services, and git plus make installed. And Razor of course. If you use something else, please make sure your setup correlates to the changes applied here.
So, to get Razor to properly boot up on the MicroServers we need to make changes in how the dnsmasq service is giving directions to our PXE-clients, and what files tftpd-hpa is serving up. First up, the file that we need here is an UNDI PXE compatible file. If you’re not deploying ESXi, you can probably stop reading now and just download the latest version from http://boot.ipxe.org/undionly.kpxe. For all you out there that want to deploy ESXi on your MicroServers (and apparently this needs to be done for Cisco UCS as well), please read on.
Download the latest IPXE code using git by running the following commands:
git clone git://git.ipxe.org/ipxe.git
Add the following to “ipxe/src/config/local/general.h”. This is needed for ESXi’s menu.c32 (bootmenu) to properly work. Otherwise you’ll get stuck at the picture below, and you don’t want that.
Then run the following command to build the new file we need:
cd ipxe/src make bin/undionly.kpxe
Copy the undionly.kpxe file to /var/lib/tftproot so we can boot with it with this command:
cp bin/undionly.kpxe /var/lib/tftproot
Now, edit the PXE boot function in your /etc/dnsmasq.conf from:
dhcp-match=ipxe,175 dhcp-boot=net:#ipxe,undionly.kpxe dhcp-boot=razor.ipxe
This will effectively skip the troublesome pxelinux part and go straight to Razor. Restart your dnsmasq service and you’re ready to go.
Voila! You’re now done and can boot up your ESXi’s perfectly. Now go deploy those HP MicroServer/Cisco UCS servers!
They should look this when you’re done 🙂
With the fix explained here:
And more reading on how to get the fix properly working with dnsmasq here: