I was recently showing someone my homelab and they noticed that I had templates for multiple Linux distributions including Ubuntu Server, Photon OS, and Tiny Core, as well as different versions of each. They asked why I didn’t standardize on just one Linux distribution or version. The version issue is easy — I can be lazy when it comes to cleaning up old templates. The reason for multiple distributions required a bit of extra explanation, so I figured I would type it up here.
Tiny Core is a very small Linux distribution that I can clone in seconds. If I want to test something like network connectivity, a new DHCP scope, scripting something against a handful of VMs, or something that deals with the disk of a VM like vSphere Replication or a VM image backup/restore Tiny Core is perfect… just enough of a VM to get the job done. Instructions on how to create such a template can be found in this previous post: https://enterpriseadmins.org/blog/lab-infrastructure/lightweight-vm-for-testing-tinycore-linux/.
Ubuntu Server is the largest Linux template I have on disk, but is still relatively small compared to a Windows template (my configured Ubuntu Server 18.04 template is ~5GB). Ubuntu is a consumer friendly distribution with current support for a lot of different packages. I have one of these VMs running PiHole and another used as a 2FA/RADIUS server that I use for Two Factor Authentication with Horizon UAG. Here is a previous post for building an Ubuntu 18.04 template: https://enterpriseadmins.org/blog/virtualization/lab-updates-ubuntu-18-04-template/
What Linux distribution do you like that I am missing?
Most of the time we want our virtual machines to run as optimally as possible. We don’t want to see CPU contention or high memory conditions. However, on occasion we may want to have some stress to see what that looks like in monitoring tools like vRealize Operations. I created two small scripts that will run in TinyCore Linux, one consuming CPU and the other memory. For info on creating a TinyCore template, you may want to check out this post: https://enterpriseadmins.org/blog/lab-infrastructure/lightweight-vm-for-testing-tinycore-linux/. Here are the scripts for reference:
cpubusy.sh
1 2 3 4 5 6 7 8 9 10 11
cpus=$(grep -ci processor /proc/cpuinfo)
echo "System has $cpus CPUs, starting thread for each."
for i in $( seq 1 $cpus )
do
echo " ..starting background process #$i to consume CPU."
sha1sum /dev/zero &
done
echo "You can check processes with 'top' sorting by CPU with 'P'."
echo "To end all processes run 'killall sha1sum'"
echo "This script will fill memory to 90% with zeros."
# disable swap, only use RAM
sudo swapoff -a
# find current system memory
mem=$(sudo grep -i memtotal /proc/meminfo | awk '{print $2}')
# calculate 90% of current memory, using 100% will cause instability
fillmem=$(expr $mem / 100 \* 90)
# tmpfs is mounted as 50% by default, remount with our 90% number
echo " ..remounting /dev/shm to use 90% of MemTotal"
sudo mount -o remount,size=$fillmem"k" /dev/shm
# show the current size of tmpfs
df -h | grep tmpfs
# fill that space with 1k block zeros
echo " ..starting memory fill process."
dd if=/dev/zero of=/dev/shm/fill bs=1k
I placed these files in the tc user home directory (/home/tc) and set them to executable with chmod +x filename.sh.
If you’d like, you can add entries to have these scripts start automatically at boot — if you want an appliance that maxes out resources all the time. To do this, use sudo vi /opt/bootsync.sh and add entries at the end of the file for /home/tc/cpubusy.sh & and/or /home/tc/memfill.sh &. Note: the ending ampersand causes the script to run in the background and not wait for completion.
Typing backup will allow you to make these files & changes persistent.
Note: its much easier getting this text copied over if ssh is installed/configured on your tinycore VM. There is a very good write up on how to do this here: https://iotbytes.wordpress.com/configure-ssh-server-on-microcore-tiny-linux/. This post also covers how to include credentials (etc/shadow) in the file list backed up by TinyCore, which is also very useful.
I’ve often found the need to have a very small VM for testing. Some use cases would be testing if a DHCP scope was working, to verify if a VM port group was correctly configured, to confirm if a site-to-site VPN tunnel was up/passing traffic, to deploy/modify with PowerCLI, and many, many more others. Typically all I’m looking for is a command prompt, a network stack, and preferably VMware Tools running. Many years ago I stumbled on TinyCore Linux — a very small distribution that with a GUI and open-vm-tools installed only took 53mb of disk space as an OVA. Such a small distribution was easy and fast to deploy and used nearly no resources, so it was ideal for testing. This OVA was super handy, I had it on various file shares, a web URL, and even as a VM Template so that I could easily get to it for testing. The OVA I created was based on TinyCore 3.6 (Linux kernel 2.6) — like I said, I’ve had this for many years. I recently went looking to see if TinyCore was still being developed and if a newer version was available. What I found was TinyCore 11 (Linux kernel 5.4) that was released earlier this month. The steps below show how you can create your very own lightweight VM based on this latest distribution.
To begin we should download the ISO. I used the CorePlus-11.0.iso from http://tinycorelinux.net/11.x/x86/release/. Once I had the ISO, I uploaded it to a datastore. (Note: These instructions were tested on an ESXi 6.7u3 host, but should be similar on different versions and/or hypervisors.) . Here are the settings I used for the new VM
Compatible with ESXi 6.0 and later (hardware version 11). Note: as of this writing ESXi 6.0 is still supported, so I made this choice to ensure a the newest features would be available while maintaining maximum backwards compatibility (to all supported platforms).
Guest OS = Linux \ Other 3.x Linux (32-bit). Note: if using a newer version of virtual hardware, additional / newer Other Linux options may exist. TinyCore is based on Linux kernel 5.4, so we want to pick the nearest option available.
Memory = 256mb. Note: I tested with lower amounts of RAM, but this was the lowest that worked consistently. Your mileage may vary.
New Hard Disk – Remove
New CD/DVD Drive > Datastore ISO File, browse to CorePlus-11.0.iso uploaded earlier and select Connect…
Expand CD/DVD Drive and change Virtual device Node to IDE1:0
Add a new device > hard disk, size = 64mb, expand details and change virtual device node to IDE 0:0
Remove the new SCSI controller as it is not used
Under VM Options tab \ Boot Options \ confirm that Firmware = BIOS (recommended). Note: if you use a newer version of virtual hardware, a different firmware option may be selected by default.
Power On VM
Open with Remote Console (not web console). Note: this requires VMRC to be installed. By default in TinyCore the mouse pointer does not work with the web console.
Once the VM boots, you should see a menu of different boot options. Select the option “Boot Core with X/GUI (TinyCore) + Installation Extension.” Here are additional settings I selected:
Once the GUI has loaded, run tc-install (the last icon on the bar at the bottom of the screen)
Select Whole Disk and sda (Frugal and install boot loader should be checked by default)
Next > ext4 > next > next > Core Only (Text Based Interface) > next > Proceed
The wizard should say ‘Installation has completed’
Click Exit on the tool bar at the bottom of the screen, then Reboot
The VM will now boot into the shell prompt of the locally installed copy of TinyCore. We will now install some additional packages from the command line. This assumes the network in use has DHCP available and we already have an IP / internet connectivity.
Note: for me, the open-vm-tools install ended with text about fuse.conf not being a file or directory. This did not cause any issues in my testing.
Next we check to ensure the new packages (pcre.tcz, open-vm-tools.tcz, and curl.tcz) are listed (one per row) in the list of packages loaded at boot (using command cat /etc/sysconfig/tcedir/onboot.lst).
In my testing, I noticed that sometimes open-vm-tools is not started correctly at boot. I’m not sure what causes this, but found a simple workaround by using a script that runs automatically at boot to restart the service. I did this by typing sudo vi /opt/bootlocal.sh
At the end of this file, I pressed i (to get into insert mode) and added the text /usr/local/etc/init.d/open-vm-tools restart. We then save & exit from file by pressing the escape key (to exit insert mode) and typing :wq (to write changes and quit the vi editor).
By default the hostname of the VM is ‘box.’ However, I wanted to set a custom value. To do this we edit the bootsync.sh script by typing sudo vi /opt/bootsync.sh. We then replace the text ‘box’ on the line for sethostname with our FQDN. Note: this isn’t how hostnames are typically set in Linux, and I would assume this would not be updated by a vCenter customization spec. I’m only adding a value for reference when I see the hostname in vCenter that is presented by VMware Tools.
When the VM boots up, there is some text that’s automatically displayed from the message of the day (MOTD) file. We want to edit this to include some simple instructions. However, the changes to the MOTD file are not persistent by default. To include this file in the list of persistent files, we need to add an entry to a file. We can do this by typing vi /opt/.filetool.lst and adding an entry for “etc/motd” (without the quotes). Now that these changes persist, we can make changes to the MOTD with the command sudo vi /etc/motd. In this example I’ve added instructions for how to set a static IP address and to use curl to test a specific TCP port:
As a cleanup step, I like to remove the command history from templates. To do this for TinyCore we can type rm .ash_history to remove the file.
To trigger a backup of the files we’d like to persist, we simply type backup and press y for yes.
With all our changes complete, we can test that the VM starts up correctly by issuing the command sudo reboot.
Confirm that VMware Tools is working and that your message of the day is displayed. On ESXi or vCenter you can confirm that VMware Tools are working by reviewing the status tab of the running VM. In this screenshot you can see that tools version 11269 is running. Clicking more info confirms that this is version 11.0.5 (the latest available as of this post).
You may notice that the Guest OS is showing Other 4.x or later Linux, even though we selected Other 3.x when creating the VM. This is because VMware Tools is presenting the property from within the guest, instead of defaulting to the property from the VM creation wizard.
You can now shutdown the VM and change the CD ROM back to Client Device (to detach the ISO image). From here we can export the VM to an OVF or convert to a virtual machine template. As an OVF this VM is roughly 19mb on disk. It will deploy very quick and is just enough of an appliance for many test cases.
Note: there are a few other recommended changes you may want to consider if you are building a template for use in VMware Fusion or Workstation that relate to display resizing and copy/paste. Those are documented here: http://wiki.tinycorelinux.net/wiki:vmware_installation.
