Title: OpenBSD vmm and qcow2 derived disks

	Title: OpenBSD vmm and qcow2 derived disks
	Author: Solène
	Date: 27 August 2023
	Tags: openbsd
	Description: In this article, you will learn how to leverage a qcow2
	feature enabling you many virtualization use case

	# 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

	# 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:

	```console
	# 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.

	# 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

	# 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.