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.

When mounting an iSCSI target on two or more servers simultaneously using conventional filesystems (ext4, XFS, etc.), data corruption is inevitable. Each server maintains independent caches and metadata in memory, creating a critical coordination gap: neither server is aware of the other’s modifications. This lack of synchronization leads to: Metadata corruption, Lost or duplicated files, Filesystem structural damage, Potential complete data loss.

To safely share storage across multiple servers, you must implement a cluster-aware filesystem specifically designed for concurrent access. Currently, the two most prominent options are: OCFS2 (Oracle Cluster File System) - Oracle’s robust, feature-rich solution; GFS2 (Global File System) - Red Hat’s scalable cluster filesystem.

In this part, we’ll focus on implementing OCFS2 across Oracle Linux servers, providing step-by-step configuration for reliable shared storage access.