Drop libvirt in favour qemu.

[Eskpil]

Libvirt is a technology that is turning 25 years old at the time of writing. While many people like to believe that age doesn’t matter, it does matter in this decision. Over the years, Libvirt has evolved to address a wide range of virtualization use cases, but many of those use cases are either outdated or irrelevant to Rockferry’s specific needs. As a result, we may be inheriting unnecessary complexity and limitations by relying on a tool that was designed for a broader, more generalized audience.

One of the primary challenges with Libvirt is its API, which is difficult to interface with, especially in Go. To interact with Libvirt in Go, we currently rely on a library provided by DigitalOcean. However, this library is not stable, and the recommended approach is to vendor it into the project, which adds maintenance overhead. Additionally, the API lacks native Golang type definitions, forcing us to rely on the pkg/virtwrap package to wrap Libvirt’s XML schema definitions into Golang types. This approach is cumbersome and impractical, as it introduces additional layers of abstraction and makes the codebase harder to maintain and debug.

Another significant limitation of Libvirt is how it handles storage. Currently, all storage pools and volumes are bound to the node, which creates unnecessary constraints. For example, if two virtual machines on different nodes need to access the same storage volume—perhaps for a Ceph use case—we must ensure that both nodes have the same storage pool configured. This often requires replicating the volume across nodes, which is not only inefficient but also challenging to implement using Libvirt’s API. Instead, I propose leveraging the information Rockferry already possesses to manage storage pools and volumes at the Rockferry instance level, rather than tying them to individual nodes. This approach would simplify storage management and align better with Rockferry’s architecture.

The primary tradeoff of moving away from Libvirt would be losing the ability to perform live migration easily. Live migration is a feature that allows virtual machines to be moved from one node to another without downtime, which can be useful for scenarios like scheduled maintenance. However, this functionality is not a priority for Rockferry at the moment, and the benefits of simplifying our storage management and reducing dependency on an outdated tool may outweigh the need for live migration. Furthermore, alternative solutions could be explored in the future if live migration becomes a requirement.

In summary, while Libvirt has been a reliable tool for virtualization over the years, its age, complexity, and limitations make it less suitable for Rockferry’s specific needs. By moving away from Libvirt, we can simplify our architecture, reduce technical debt, and build a more maintainable and scalable system. The tradeoffs, such as losing live migration capabilities, are manageable and do not outweigh the potential benefits of adopting a more modern and purpose-built solution.