Many of my VMs are headless servers, for application software that (when under a light load) will run fine under 512MB of Memory. However, PXE Boot Images and the Install Image that runs the Anaconda Installer load a virtual ramdisk into memory. With each Distro Release, it seems the size of that ramdisk grows.

The workaround is to allocate the VM 1536MB of vRAM for the installation phase. And then, post installation revisit the VM Settings to reduce the vRAM allocation to 512 MB.

2018-12: The updated CentOS “1810” boot images require 1,536 of vRAM for PXE client to boot and successfully run the Anaconda installer. After install is complete, reducing the VM allocation to 512MB Memory is ok.

2018-10-04: PXE clients fail if less than 1,248MB of vRAM, (the boot image uses a ramdisk). After install is complete, reducing the VM allocation to 512MB Memory is ok.

The files needed by PXE clients can be downloaded from the internet and placed into the target directories, bypassing the need to download ISOs at all. Now that you’ve seen a couple sets of PXE Boot image files, you can figure out which equivalent files to download directly.

For CentOS and Fedora, the online repos usually follow a naming/pathing convention like these examples:

(live URLs as the time of this writing)

http://mirror.centos.org/centos/7/os/x86_64/

http://mirror.centos.org/altarch/7/os/i386/

http://mirror.centos.org/centos/6/os/x86_64/

http://mirror.centos.org/centos/6/os/i386/

https://mirrors.kernel.org/fedora/releases/29/Everything/x86_64/os/

For RedHat (RHEL) and Oracle, their subscription managers add a little bit of complication, but the pattern is essentially the same. One of the simplest approaches for RHEL is to:

use a subscribed node to run a reposync script against the desired repos,

cp the PXE boot/install images from a downloaded ISO (matching the ReleaseVersion/Arch), compare the ISO location of the boot images to their online repos and find the correct URL path/pattern for future use.

To provide a local PXE/Kickstart for Fedora 29, refer to these steps as a starting point.

note: across the family of CentOS/Fedora/RHEL/Oracle… these boot/install images vary by release, version, iso-version, etc, etc… sometimes it is necessary to do a little reading, and try more than one file to find the ones that provide a successful PXE/Kickstart in your environment.

Download just the boot images. Then,using previous sections as a template, create a filtered yum config and a reposync script to get just the packages needed to install your desired config.

Just create a new VM instance, and don’t provide it with any installation media.

Of course it will need a vdisk for the installation to work, use ~6 or 8gb set as NVMe.

For headless servers, there usually isn’t any need for Bluetooth, Sound, 3D Video, or a Printer Port. I remove all of those from VM hardware profile.

The PXE/Kickstart install image the clients will boot utilizes a ramdisk. In current/recent versions of CentOS, Fedora, RedHat, and Oracle linux clients need 1,536 MB of vRAM to load this installation image. As soon as the installation is completed, and the VM is capable from using it’s own disk, then the VM hardware memory allocation can be reduced… for many of my server VMs, I set it at 512MB.

1 vCPU is adequate.

Of course it will need a virtual network interface configured on the same VMNET as Fusion is providing DHCP with the PXE (“next-server”) option.

That’s it… start the VM.

If it works, there will be a lot of scrolling text… then eventually a prompt to quit/reboot… and you’ll have a working VM.

If something goes wrong, watch the screens, it’ll provide pretty good clues. There are also methods to access (tail) the installation logs… but I’ll leave you to read up on that. Most of the problems with relatively simple PXE/Kickstart setups like this are due to typos in the *.ks script or the “default” pxe boot menu.

This config is on the VMware host. In my case, that’s a MacOS Mojave MacBook Pro running VMware Fusion. Any recent VMware hypervisors (Fusion, Workstation ESXi) are capable of providing this. VirtualBox and Parallels can to. This scope of this guide is staying with VMware Fusion on MacOS.

Fusion doesn’t provide a GUI interface for the DHCP PXE Boot Server option. But it does support a lot of additional features through config files and/or the command line.

For this step, open a MacOS Terminal window, and:

sudo su

nano /Library/Preferences/VMware\ Fusion/vmnet2/dhcpd.conf

Put this after the “DO NOT MODIFY” section of stuff… it’s “reimplementing the subnet”…

note: on the PXE Boot Server, the “pxelinux.0″ file can be put in a subfolder, and then referenced in the DHCP config with this syntax ” filename “pxelinux/pxelinux.0”;

My PXE server is providing the pxelinux.0 file at the default root of the tftpserver.

the vnet dhcp config is a little less than obvious…

the PXE Boot TFTP Server is represented by: “next-server 10.0.0.11”

subnet 10.0.0.0 netmask 255.255.255.0 {

range 10.0.0.128 10.0.0.254;

option broadcast-address 10.0.0.255;

option domain-name-servers 10.0.0.2;

option domain-name localdomain;

default-lease-time 1800; # default is 30 minutes

max-lease-time 7200; # default is 2 hours

option netbios-name-servers 10.0.0.2;

option routers 10.0.0.2;

next-server 10.0.0.11;

filename “pxelinux.0”;

}

host vmnet2 {

hardware ethernet 00:55:55:C0:22:22;

fixed-address 10.0.0.1;

option domain-name-servers 0.0.0.0;

option domain-name “”;

option routers 0.0.0.0;

}

* for simplicity, this VMNET config uses an entire class c range (private/non-routable of course), and then allocates the bottom half for static IP and lets the DHCP process serve the top half.

We’re going to make a folder structure that supports two Distro/Release/Arch versions to start with, and can easily be updated with additional versions down the road.

mkdir /var/lib/tftpboot/CentOS7x64/

mkdir /var/lib/tftpboot/CentOS7x32/

Now, to copy the minimum boot files over to the tftpserver… we need to mount an installation media ISO… such as “CentOS-7-x86_64-NetInstall-1810.iso” for CentOS 7 64-bit, and cp the boot files to the tftboot directories.

The exact details of mounting media (ISOs) can vary…

I’m doing this on VMware Fusion, and the vm has open-vm-tools installed and active, so, my method is to use vmware to choose and connect the disc image to the VM, then, within the vm: