About me: My name is Solène Rapenne, pronouns she/her. I like learning and sharing knowledge. Hobbies: '(NixOS BSD OpenBSD Lisp cmdline gaming security QubesOS internet-stuff). I love percent and lambda characters. OpenBSD developer solene@.

Contact me: solene+www at dataswamp dot org or @solene@bsd.network (mastodon). If for some reason you want to support my work, this is my paypal address: donate@perso.pw.

Consider sponsoring me on Patreon to help me writing this blog and contributing to Free Software as my daily job.

OpenBSD vmm and qcow2 derived disks

Written by Solène, on 27 August 2023.
Tags: #openbsd

Comments on Fediverse/Mastodon

1. Introduction §

Let me show you a very practical feature of qcow2 virtual disk format, that is available in OpenBSD vmm, allowing you to easily create derived disks from an original image (also called delta disks).

A derived disk image is a new storage file that will inherit all the data from the original file, without modifying the original ever, it's like stacking a new fresh disk on top of the previous one, but all the changes are now written on the new one.

This allows interesting use cases such as using a golden image to provide a base template, like a fresh OpenBSD install, or create a temporary disks to try changes without harming to original file (and without having to backup a potentially huge file).

This is NOT OpenBSD specific, it's a feature of the qcow2 format, so while this guide is using OpenBSD as an example, this will work wherever qcow2 can be used.

OpenBSD vmctl man page: -b flag

2. Setup §

First, you need to have a qcow2 file with something installed in it, let's say you already have a virtual machine with its storage file /var/lib/vmm/alpine.qcow2.

We will create a derived file /var/lib/vmm/derived.qcow2 using the vmctl command:

# vmctl create -b /var/lib/vmm/alpine.qcow2 /var/lib/vmm/derived.qcow2

That's it! Now you have the new disk that already inherits all the other file data without modifying it ever.

3. Limitations §

The derived disk will stop working if the original file is modified, so once you make derived disks from a base image, you shouldn't modify the base image.

However, it's possible to merge changes from a derived disk to the base image using the qemu-img command:

Red Hat documentation: Rebasing a Backing File of an Image

4. Conclusion §

The derived images can be useful in some scenarios, if you have an image and want to make some experimentation without making a full backup, just use a derived disk. If you want to provide a golden image as a start like an installed OS, this will work too.

One use case I had was with OpenKuBSD, I had a single OpenBSD install as a base image, each VM had a derived disk as their root but removed and recreated at every boot, but they also had a dedicated disk for /home, this allows me to keep all the VMs clean, and I just have a single system to manage.