Jeff - would this be a qemu build type issue or perhaps an even more generic buildroot type problem?

This is all going to be dependant on what version of librbd is present in the build roots for RHEL-AV stream.  If the build root is correct, it shouldn't involve any code changes in QEMU. Perhaps at most a version number tweak in the RPM specfile to express a min dependency.

I think this question needs to be answered by the ceph team; as Daniel rightly points out, qemu-kvm simply builds against whatever is in the build root. Boris, is this something you can do?

Is there any specific benefit that will require build-time use of librbd1>=14.2? Unless there is a specific new librbd API method that you are attempting to use via qemu's RBD block driver, you should just be able to install the updated packages from "rhceph-4-tools-for-rhel-8-x86_64-rpms" and qemu-kvm will utilize the new librbd1 shared library at runtime. Assuming qemu-kvm v2.12, it looks like the only build-time feature that is not enabled due to the older packages is a iovec-based IO dispatch calls.

(In reply to Jason Dillaman from comment #5)
> Is there any specific benefit that will require build-time use of
> librbd1>=14.2? Unless there is a specific new librbd API method that you are
> attempting to use via qemu's RBD block driver, you should just be able to
> install the updated packages from "rhceph-4-tools-for-rhel-8-x86_64-rpms"
> and qemu-kvm will utilize the new librbd1 shared library at runtime.
> Assuming qemu-kvm v2.12, it looks like the only build-time feature that is
> not enabled due to the older packages is a iovec-based IO dispatch calls.

hi Jason, this would be to release in OpenStack some new code which only works with mimic (or newer) clients.

Assuming we do get 14.x (nautilus) RPMs installed on the compute nodes, are qemu-kvm guests seen as mimic clients even if qemu-kvm itself is built against 12.x (luminous) libs?

(In reply to Giulio Fidente from comment #6)
> hi Jason, this would be to release in OpenStack some new code which only
> works with mimic (or newer) clients.

further details about that are in BZ#1764324

(In reply to Giulio Fidente from comment #6)
> hi Jason, this would be to release in OpenStack some new code which only
> works with mimic (or newer) clients.
> 
> Assuming we do get 14.x (nautilus) RPMs installed on the compute nodes, are
> qemu-kvm guests seen as mimic clients even if qemu-kvm itself is built
> against 12.x (luminous) libs?

Yes, the qemu-kvm clients will be seen as whatever version of librados2 is installed and being used at runtime regardless of what they were built against. 

As an aside, I too would love to see RHEL 8.x upgrade its AppStream version of the Ceph client libraries to RHCS 4 since RHCS 3 is effectively EOL (on extended support only).

Doing a (major) rebase in RHEL is highly non-trivial and not something we are currently looking into.

You can always check for the availability of the API calls you need and use them if they are present. I was under the impression that qemu already does this. Am i wrong there?

If this is for openstack they did even ship their own version of ceph at some point (hopefully not anymore) so it shouldn't be a problem to implement it this way for them.

They should be seen as mimic (or up) clients, you are using the shared library that is installed on the system, not the one it was compiled against. We don't use static binaries in RHEL (there might be some rare exceptions but this is not the case).

Having said that, you will also need the Ceph server to support the calls/features so you might need to implement the checks for the API calls anyway.

Re-titling the BZ and setting it to the right component (ceph), as this is not something for QEMU itself to fix.

This is a request to rebase librados2 in RHEL. QEMU simply makes use of what's available there.

A separate request can be made if there's something specific that needs to be supported in QEMU (something for us to work upstream)

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.