Re: Can I contribute Vitastor block driver? Or maybe introduce a QAPI plugin system?

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3045 bytes --]

On Wed, Mar 26, 2025 at 10:38:11AM +0100, Markus Armbruster wrote:
> I'm not speaking for the QEMU project.  I hope to be helpful anyway.  I
> am the QAPI maintainer, so my thoughts carry a bit more weight there.
> 
> I understand your block driver depends on your libvitastor_client
> library.
> 
> Dependencies that aren't available on at least one supported build
> platform (and thus covered by CI) are problematic.  For Linux,
> "available" generally means "provided by the distribution".  I doubt
> there's a way around getting your library packaged by distributions.
> 
> The QAPI schema is (for better or worse) fixed at compile time by
> design.  Changing that would be a major undertaking.  Whether the
> benefits could justify the costs and risks seems rather doubtful to me.
> 
> In my experience, the project invites contributions, not out-of-tree
> extensions.  The latter require external interfaces, which can only be
> harder to maintain than internal ones.  There's also the risk of abuse
> to circumvent the GPL (I have absolutely no reason to assume you'd try
> that!).

I want to share experience with QEMU block drivers over the years.
Special-purpose QEMU block drivers are being used less in favor of host
kernel drivers. Kernel drivers make the storage available to all
workloads (e.g. containers) on the system, not just QEMU VMs. In
particular, it reduces the amount of QEMU-specific support needed to
integrate into orchestration software (e.g. Kubernetes). Just a single
storage plugin for, say, Kubernetes, enables both container and VM
workloads if you provide a host kernel driver for your storage.

There can be performance advantages of implementing a QEMU block driver
compared to a host kernel driver, but I think in the long term it's
worth prioritizing a host kernel driver because it will reduce
maintenance for you and make your storage usable with more types of
workloads.

But the decision is up to you. A QEMU block driver might be preferrable.

Some more details about what Markus mentioned:

The first step is to ensure that dependencies are under licenses that
are compatible with the GPLv2.

If you want the block driver to be widely available to users, the next
step is to get dependencies packaged for for popular Linux distros. The
distro's QEMU packages need to link against the dependencies, so they
need to be in the distribution's package repositories, not in
third-party repositories.

Alternatively, if you will continue to distribute your own QEMU and do
not want to go through the effort of getting the dependencies into
distros, then you could contribute continuous integration (CI) jobs that
build with the third-party dependencies. However, the disadvantage is
that most users will be unable to use the block driver and the userbase
will be greatly limited.

Both of these approaches put the block driver (and associated QAPI
schema changes) in qemu.git/master and you would be the maintainer of
the block driver.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]