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

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

[vitalif]

Hi!

I'm the author of Vitastor SDS (https://vitastor.io/). My project is an opensource SDS with an architecture similar to Ceph, but simpler and faster - in the terms of latency, it's ~10x faster, it easily reaches 0.1ms T1Q1 latency with NVMe disks.

I have a custom block driver for qemu (block/vitastor.c), currently I package it manually and provide my own QEMU packages.

I wanted to ask if I can submit this driver to you to package it upstream? It requires libvitastor_client library to build which is also currently available either in source form or from my repositories, is it fine?

And actually, if that's a problem, another option for me would be to use a hypothetical QAPI plugin system if QEMU had one - because, in fact, the only thing which is forcing me to rebuild QEMU is qapi/block-core.json. I have to patch it because, otherwise, the JSON options of my block driver aren't accepted by QEMU. So if there was a way to dynamically load these qapi definitions it would allow me to make compatible *.so block driver builds easily, even though there's no "stable" API as I understand. I'd just need a separate build for every qemu version, but that's not a problem for me :-). Or maybe such thing already exists and I just miss it?

What do you think?

-- 
Thanks in advance,
  Vitaliy Filippov

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

[Markus Armbruster]

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!).

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

[Stefan Hajnoczi]

[-- 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 --]

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

[vitalif]

Ok, thank you very much for the information!

So I should first try to make my library available in one of the distros used for CI. As I understand these are Alpine, Ubuntu, Debian, Fedora, CentOS and OpenSUSE. OK, I'll try it first :)

Regarding QAPI, I'd say it would be cool if it was allowed... I'm not sure if GPL circumvention is a real risk, because in some way it's already possible via the vhost-user protocol %). But it's up to you to decide of course :)

> 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!).