This post explains a small libvirt patch that adds qcow2 (and other qemu image formats) support when creating volumes on logical (CLVM) storage pools. The patch lets libvirt use qemu-img to initialise a LV as a qcow2 image and then expose that LV to a VM as a block source while preserving activation locking behavior for clustered LVM setups.

This post documents how to fetch, patch and rebuild libvirt (libvirt 10.0.0) on Ubuntu 24.04. The instructions show how to obtain the original source (Launchpad / Ubuntu archives), install build dependencies, apply local patches, and produce installable .deb packages.

The upstream Ubuntu libvirt source and recent packaging patches are available on Launchpad: https://launchpad.net/ubuntu/+source/libvirt

In this guide, I walk through rebuilding libvirt-daemon-driver-storage-logical on Oracle Linux 9 and applying a custom CLVM + sanlock patch.

The goal is to produce a rebuilt RPM that can be installed cleanly on Oracle Linux 9 systems while preserving the distro packaging workflow.

In clustered environments, CLVM with lvmlockd and sanlock is a common approach for shared storage. In practice, libvirt’s logical pool behavior can conflict with that model when one host encounters an LV lock held by another host. This patch targets a practical operating model: shared VG visibility with exclusive LV activation (except migration workflows coordinated by an external control plane).

As a developer, I’ve been using various AI tools in my work to gather knowledge, troubleshoot issues, and polish code. My usual suspects have been ChatGPT and DeepSeek, which have served me well for general queries and code suggestions. However, when I recently worked on a project that was almost entirely written with the help of ChatGPT and GitHub Copilot, I hit a wall – exceeding my quota limits. This led me to search for a viable alternative that could meet my specific requirements.

KVM supports “Shared Mountpoint” storage. A shared mountpoint is a file system path local to each server in a given cluster. The path must be the same across all Hosts in the cluster, for example /mnt/primary1. This shared mountpoint is assumed to be a clustered filesystem such as OCFS2. In this case the CloudStack does not attempt to mount or unmount the storage as is done with NFS. The CloudStack requires that the administrator insure that the storage is available.

In this part, we will introduce how to use OCFS2 in Apache CloudStack.