This is post #4 in my December 2013 series about Linux Virtual Machine Performance Tuning. For more, please see the tag “Linux VM Performance Tuning.”
In this day & age of virtualization and clouds the best choice for an OS installation, be it a virtual machine template or a physical machine, is a minimal install. From there you can use a configuration management tool like Chef or Puppet to add exactly the packages you need for the host to perform its functions.
Doing a minimal install has several advantages:
- A minimal installation doesn’t install a lot of content that will just sit there and consume disk space. As a result your template VMs will be really small, which leads to fast provisioning times, fast VM-level replication, fast VM backups, fast snapshots, lack of wasted space on disk, and good opportunities to use thin provisioning to its fullest.
- A minimal installation doesn’t have unused content that runs as services, wasting RAM, CPU, disk I/O and capacity (think logging). Unnecessary content on a VM also increases the security attack surface of the VM (attack surface == the amount of stuff that will be attacked to gain access to a host).
- Ongoing maintenance of a minimal VM is also not wasteful. You don’t spend a lot of time patching things you don’t use on the host. You don’t store a lot of cached copies of RPMs and whatnot, ballooning your thin-provisioning, wasting network bandwidth moving copies of updates around that you don’t really need. Doubly so for replicated VMs, and anything you’re doing VM-level backups for. Really, how much unnecessary stuff do you want to copy around the planet?
- Biggest of all: saving disk space, disk performance, CPU, RAM, and network bandwidth saves lots of money, both on premise and in the cloud, and with configuration management tools it isn’t at the expense of staff time.
Lean & mean is the goal. But lean & mean doesn’t have to mean inconvenient. If you’re using a configuration management tool like Chef or Puppet to help provision VMs you end up figuring out exactly what needs to be configured on a host once, then you’re set for the life of that OS because that tool will take care of all the details in future deployments. And my “minimal” installs include a lot of unprovisioned, unformatted disk space. It just sits in the LVM volume group, zeroed out, so if I (or the provisioning system) need to add space to a filesystem it’s easy to do. Most of my VMs have 30 GB thin-provisioned disks but are only occupying 2-6 GB on disk.
I generally let Puppet do all of my configuration for me, but there are a couple of things that are easier to do at system install time. I try to follow the Center for Internet Security’s configuration benchmarks and some of those recommendations need separate filesystems for /var/log and /var/log/audit. It’s fairly tricky to add these as filesystems after the fact, and nearly impossible for Puppet to do, so I build it in at install time.
I’ve published the minimal Kickstart file I use, along with some commentary about it. I’m writing about Linux here, and the Enterprise Linux family specifically, but there are analogs to all of this for every OS.
——
Photo of marbles in jars © alexkerhead, via Flickr, licensed with Creative Commons CC-BY 2.0.
It’s no where near impossible for Puppet to add volumes after install. Use of modules like puppetlabs-lvm (https://github.com/puppetlabs/puppetlabs-lvm) make it pretty seemless and easy if you’re already setting up your system to use LVM during kickstart (which I see you are with your minimal config).
We use this pretty extensively in our environment to managing FS sizing across hundreds of nodes.
Travis, didn’t mean to imply that I don’t — I also use and enjoy the LVM module. For instance, I add a filesystem for /var/www when I assign a host a web server role. It’s just a lot easier to have space there to use than have to add another VMDK. Might as well use thin provisioning to save some work, as well as money. 🙂