Skip to main content

VDO with Custom Kernel

By July 15, 2021No Comments

VDO with Custom Kernel

Well now, if you’re reading beyond the title, then either you’re curious about VDO, or you’re already running it and you have the same troubles I ran into.

Running VDO on CentOS 7.5


My laptop runs CentOS 7.5 and to accomodate newer hardware (mainly USB-C dongles) I run a (non-standard) mainline kernel, specifically el-repo’s kernel-ml, which at the time of writing is at version 4.18. I use VDO to crunch down my libvirtd VMs path, to reduce their footprint as much as possible. VDO itself is available as a pre-packaged RPM via yum repositories for CentOS 7.5 and is prepared for 3.10 kernels specifically. I don’t know of any way to make those RPMs compatible with my 4.x kernels, so I chose the build-from-source route. Note that VDO consists of both the user tools and the kvdo kernel module.

Rebuild VDO from Source with Mainline Kernel, using Ansible

Seeing as how el-repo releases the latest mainline kernel rather quickly, re-doing the manual steps of installing VDO from source, it’s tedious and is better off automated. Given that, I whipped up an Ansible playbook to handle it. For clarity, I’ve tested this with Ansible 2.6 on CentOS 7.5, but I’m guessing this would work on Ansible 2.3+ and CentOS 7.3+ (but don’t quote me there).

Want to give it a try? just git clone this repo and do the following as the root user or with a -b for become (and then -K for password)..

ansible-playbook -i localhost install-vdo.yml -v

Once complete, given there were no errors, if you run a vdostats, and see output, but NO errors, then you’re all set!

Essentially, after each yum update brings you a new 4.1x kernel, you’ll have to run this playbook, but thankfully so, instead of hand-writing all those lines.

Do note that there are some oddly finnicky settings in use when rebuilding regularly with this method. Sometimes you may need to purge the old repo clones and related files.

What is VDO?

Are you still curious about VDO? In short, it’s a compression/ deduplication/ zero-block-omission layer for Linux filesystems. It has great use-cases in cloud deployments, where we often see a lot of resources put towards storage, so why not do what we can to reduce what storage we consume? If you’re looking for more details, there’s a blog here for further reading.

Perhaps you’re further intrigued about getting VDO in use for your (cloud) storage? We’d be glad to talk about that! Until then, practice safe cloud-ops!