PXE Server Configuration Tutorial

Configuring a PXE server to present the files and information needed for kickstarting your ESX hosts isn’t too difficult a task. It does require some basic unix/linux knowledge, but aside from that, not too bad. I use a CentOS virtual machine with just 256 MB of RAM (you’ll need at least 512 for a GUI, but one isn’t necessary) to act as the PXE server for my ESX hosts. This same virtual machine also serves as a management point, as it has access to the management lan and with the perl toolkit and rCLI installed I can automate much of the work I need to accomplish with the hosts.

I happen to segregate the different types of traffic on the ESX hosts onto different VLANs. This means management (COS/PXE), VMotion, IP Storage, and virtual machine traffic (usually several VLANs by itself) are all separate. It is important that the server (or virtual machine) that you are using is configured with at least one interface on the same VLAN/network that the ESX management network is on. That interface will also need to have a static IP address.

It is also important that DHCP is able to function on this network when the host is in a totally unconfigured state. This means if you are trunking to your ESX hosts you must have the native VLAN set to the same as your management VLAN and port channeling (802.11q / LACP) can not be turned on during the PXE process.

The first step for PXE is DHCP. When your server is told to PXE boot it will broadcast a DHCP request, which your PXE server will then respond to with an IP and instructions to forward onto the pxelinux file contained on itself.

tftp (Trivial File Transfer Protocol) is the service that provides the ISOLinux files to your ESX host during the PXE boot process. If you do not have xinetd installed, you will also need to install it. xinetd is generally considered a security risk because it allows services and functions to be executed with little or no authentication (to include tftp). Since we are (theoretically) on a closed network the risk should be mitigated somewhat. You can also configure your firewall to drop all traffic from any interface execpt the ESX management lan that is destined for the xinetd services.

syslinux is what does the majority of the work. syslinux is a very small linux OS that is sent to the host during the boot process. It then reads it’s config files and will present the user with options for booting (or just autoboot a particular option, depending on configuration).

Now that we have everything in place, the last step is to configure the menu(s) that are displayed to the user and place the initrd and kernel images in the correct place.

The ESX hosts will mount an NFS directory to get their OS files and post kickstart config scripts. We need to configure NFS to export the correct directories.

The most common problems I’ve seen have to do with permissions. Make sure that all the configuration files are at least “644” permissions, which ensures that all users can at least read them. This is especially important with the media files (/export/kickstart/media), as the remote server will be connecting as “nfsnobody” (because we specified “all_squash” in the /etc/exports file).

If you are unsure about what’s happening during the process, watch the log file (tail -f /var/log/messages), it will tell you when a DHCP request is received, the IP that was assigned to a particular MAC, when NFS mounts and unmounts are performed (and what IP they are from) and other error messages on the PXE server side. During the Annaconda load process you can press Alt-F3 or Alt-F4 to see particular operations happening (logs and such). Additionally, after a certain point you can press Alt-F2 to get to a very basic shell.

That should get you up and running with kickstart. Generally speaking, PXE, Anaconda (the ESX installer), or ESX itself will tell you when there is an error and what went wrong. If you are uncomfortable writing kickstart files by hand, you can use the kickstart generator that is provided with ESX by following VMware’s directions to enable the generator. If you are interested in the full potential of kickstart, be sure to checkout Redhat’s documentation on the subject (since they created kickstart and all). Additionally there is some really great information in the Communities forums.

If you happen to use these directions, please let me know of any errors/typos so I can fix them (thanks!).

3 thoughts on “PXE Server Configuration Tutorial”

  1. i have the problem in redhat linux enterprise 5,
    problem is TFTP pxeT01 filenot found,
    TFTP pxeE3B file not found, this is my problem please help me for this

  2. when I config the bind9 with command system-config-bind in grafical mode after configuration dns server i recived the quaries, but when i doing in command mode named.conf i did not get the dig answer

  3. @srikanth: Remember that the paths that are provided in /tftpboot/pxelinux.cfg/default are relative to /tftpboot. If you are sure they are correct, ensure that the permissions are 644 minimum on the files and 755 on the folders.

    Bind is a DNS server…you shouldn’t have to configure DNS for PXE to work. I use an unrouted network which works fine (using IP addresses).


Leave a Reply