Whether you are using CentOS for a build server or simply testing out a new configuration, you can quickly create a VM (virtual machine) that is under 1GB. You can do this without downloading any special tools or ISO files — just the CentOS installation DVD and VirtualBox (or VMware if you prefer).

I like the text-based console, so you won’t be getting a GUI or fancy Linux desktop with this one. Given its small size, you could also archive the entire environment (or even several of them) for future use without having to waste gigabytes of free space. These environments also serve as a base which can be upgraded or added onto to provide more functionality later.

All you need is a CentOS installation DVD or CD and a Kickstart configuration file for a mostly unattended installation. The Kickstart configuration consists of just a single file that can be easily served over a HTTP server (see below for downloads). If you do not have a HTTP server, you can use Python to start one on port 8000 on-the-fly:

python -m SimpleHTTPServer

With default settings, VirtualBox creates new VMs that use the NAT configuration, so it has a DHCP server that provides VMs with 192.168.56.x addresses. The host machine is fixed to 192.168.56.1.

Before starting your VM, make sure it has been allocated enough disk space (at least 3GB, but could be dynamically allocated) and that it has enough RAM & CPU to not be too slow.

Features

• Easy shutdown by pressing Host + H (ACPI shutdown)
• Boots into a console login prompt
• Larger console size with vga=773
• Disabled cursor blinking & console blanking

Installation

1. Start the HTTP server serving ks.cfg on port 8000

2. Start the VM with the CentOS ISO mounted. It should then boot into the menu.

3. Select the first item, but press TAB to specify our kickstart configuration.

4. Append ks=http://192.168.56.1:8000/ks.cfg to the kernel command line.

5. Watch the boot process acquire a network address and try to pull ks.cfg from the local HTTP server. From here on, the entire process is fully automated.

On my system, it takes slightly under 3 minutes to complete an installation. The VM should then reboot into a text console, where you can login as root with the password password.

Shrinking the VM

The packages installed by a minimal Kickstart configuration will utilize about 638MB of space (df reports 790MB). I believe we can do better. Here’s a treemap visualization of the filesystem after installation:

Notice that the treemap is dominated by /lib/modules (where kernel modules are kept), and /usr/{share,lib}/locale. We can try to remove unnecessary files, starting in those areas.

Locales (68 MB)

Since English is my primarly language and I’m fine with the date formats and stuff using en_US, we can just discard the rest of those locales and languages. This shaves off about 68MB in the locale directories.

Documentation & man pages (38 MB)

I am already familiar with the commands and I don’t think I will need to read the change log of some programs within the VM, so those can be removed as well. This discards about 38MB of documentation from /usr/share.

Kernel modules & firmware (124MB)

The VirtualBox VM is not going to gain new hardware devices very frequently, so why should the drivers for hardware devices be retained? Note that VirtualBox does however support USB pass-through so the USB-based device drivers should be kept.

For this, I wrote a Python script called modstrip.py which lists kernel modules that can be removed. It’s based on the simple idea that whatever kernel modules required to boot the OS is already loaded, and adding USB drivers to that list will form the set of modules to keep. The remaining modules not in this list are passed to xargs rm for removal.

If the kernel-firmware RPM is also removed, this step further frees up about 124MB of space.

Before & After

After pruning, the treemap shows that space is no longer being dominated by non-essential files, but rather the binaries. I’m sure more items can be removed from /usr/share but it’s going to be a never-ending quest and a lot more work for a little bit more gain.

We managed to shave off almost half of the distro size. The total size of the distro now weighs a little more than 300MB. Note that df reports 442MB instead.

Customization

You could select a different set of packages, depending on what you intend to use the VM for. For example, if this was some kind of build server, you could include gcc and make. You can also customize the installed image using the %post section, which is where the VM shrinking happens. Such customization is done by manually editing the ks.cfg file.

The Kickstart configuration expands to fill your entire VM’s “hard disk”, so you may want to use a dynamically-allocated storage type to save space. You can create a large virtual disk depending on your needs, but I usually just leave it set at 8GB.

Even Smaller

If you’d really like to set up some custom image which you then pass to someone else, use a specialized appliance-like distro instead. The libraries shipped with these distros are also different from what’s on CentOS/RHEL, so you won’t be able to use this to test or compile binaries for existing platforms.

For shipping “appliances”, Tiny Core Linux is a good starting platform at 8MB. You can also look at supermin (previously called febootstrap) to strip the distro down to its
bare essentials. Minifying distros are also useful for building images for embedded devices.

Why Should I Use This?

This method is automated and repeatable, not only by you. It utilizes an existing installation DVD, without requiring a customized ISO or any specialized tools.

When new packages are released you can just yum update to get them without having to re-install the entire OS. If you forgot to install packages that wasn’t covered by the Kickstart configuration initially, just use yum install to install them.

Screwed up the VM beyond repair? Just “insert” the CentOS DVD, start up the HTTP server with ks.cfg and hit Host + R to reboot the VM and start over. Since the installation is scripted with Kickstart, it’s fully automated for an unattended installation process.

I use this method to build and test binary RPMs for my server (also running CentOS). This provides me with a system to test configurations or software packages without running them directly on the server.

Download

Clone the hg repo and run the HTTP server from that directory:

hg clone https://bitbucket.org/geekman/minimal-centos-ks