On CentOS Stream 10 (aarch64, Ampere), libvirt cannot use an existing ZFS pool because the libvirt-daemon-driver-storage-zfs backend is not available. Attempting to reference an existing pool fails with “missing backend for pool type 12 (zfs)”. Environment OS: CentOS Stream 10 (aarch64) on Ampere Altra libvirt: 11.8.0 (Stream 10) (replace with rpm -q libvirt-daemon libvirt-client) ZFS: native ZFS on Linux with kernel modules loaded (e.g., modinfo zfs, zpool status) Steps to Reproduce Ensure ZFS kernel modules are installed and an existing pool is available (e.g., vmfast). Tell libvirt to use that existing pool (not create a new one), e.g.: virsh pool-define-as --name zfs --source-name vmfast --type zfs virsh pool-start zfs (Same failure is visible when selecting an existing ZFS pool in virt-manager.) Blocks ZFS-backed virtualization workflows that rely on existing pools. Forces inferior workarounds (file-backed storage on mounted datasets), losing ZFS-native advantages. libvirt-daemon-driver-storage-zfs enables libvirt to treat ZFS datasets as storage volumes without zfs-fuse. There is no dependency on zfs-fuse; users provide and manage their own ZFS kernel modules. Shipping the libvirt ZFS storage driver does not require Fedora/Red Hat to maintain ZFS kernel code. Reproducible: Always Steps to Reproduce: Ensure ZFS kernel modules are installed and an existing pool is available (e.g., vmfast). Tell libvirt to use that existing pool (not create a new one), e.g.: virsh pool-define-as --name zfs --source-name vmfast --type zfs virsh pool-start zfs Actual Results: Both CLI and virt-manager fail with: Error: internal error: missing backend for pool type 12 (zfs) Expected Results: libvirt should recognize the ZFS storage backend and allow defining/starting a storage pool that references an already existing ZFS pool, enabling use of ZFS datasets for VM storage . Additional Information: Using mounted datasets with file-based disks (functional but degrades performance and manageability). No native ZFS pool usage possible without the driver. Build and ship libvirt-daemon-driver-storage-zfs for CentOS Stream 10 (including aarch64), re-enabling the ZFS storage backend.
The libvirt builds for CentOS Stream & RHEL intentionally build with a minimised configuration, limiting the featureset to only that which can be directly supported in CentOS/RHEL. ZFS is not shipped as part of CentOS Stream, hence it is also not enabled in libvirt.
I understand the rationale for centos/rhel. But not for Fedora. I think it can be enabled in Fedora and disabled in Centos/RHEL. The trigger on zfs-fuse does not make sense. Can we have it in Fedora ?
Libvirt depends on the ZFS command line tools which were removed from Fedora, hence it was disabled in libvirt spec since that point.
Thanks for the context and for keeping the distro builds sane. I understand why ZFS is disabled by default. I rebuilt libvirt on CentOS Stream 10 (aarch64, Ampere) with libvirt-daemon-driver-storage-zfs and confirmed two things: without the driver, virt-manager/virsh can’t reference an existing pool (missing backend for pool type 12 (zfs)); with the driver, the same host immediately exposes my existing pool/zvols in the storage browser, and pool-* / vol-* flows work as expected. As crobinso noted, VM performance doesn’t depend on the driver—I can still point a disk at /dev/zvol/...—but the native pool/volume UX is what encourages people to actually use ZFS sanely. The dependency here is purely on the user-space tools: the backend shells out to zfs/zpool. There’s no linkage to ZFS kernel bits and no implied kernel maintenance burden. If the tools aren’t installed, the backend is inert. That’s why I’m proposing a middle path: ship the ZFS storage driver as a package on Fedora and Centos. With clear wording that it requires third-party OpenZFS user-space/kernel and is not supported by the distro. No hard Requires—at most a Suggests—so minimal installs remain clean, and expectations stay clear. If Stream is still too sensitive, enabling this on Fedora alone would already help a lot. I’m fine continuing with my COPR rebuild (1) and won’t push a closed decision, but if you’re open to it I can share the tiny spec diffs I used to keep this strictly user-space and optional. This feels like a good compromise: preserve support boundaries, reduce user confusion, and restore useful UX for those who bring their own ZFS stack. UX matters because it is an enabler for adoption. KR, Bert (1) https://copr.fedorainfracloud.org/coprs/bdherouville/libvirt-zfs/
In context of Fedora, I recalled we already have precedent for having features enabled which depend on 3rd party provided binaries - eg cloud hypervisor and virtualbox drivers, so it is contradictory to disable ZFS. We should have merely removed the RPM deps on zfs-tools, but left the driver enabled.
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
I would like to add that removing zfs with fedora 43 is causing the dnf upgrade to now fail with this error: Problem: installed package libvirt-daemon-driver-storage-zfs-11.9.0-2.fc42.x86_64 requires libvirt-daemon-driver-storage-core = 11.9.0-2.fc42, but none of the providers can be installed - libvirt-daemon-driver-storage-core-11.9.0-2.fc42.x86_64 does not belong to a distupgrade repository I can't remove zfs from fedora 42 as that would remove 75 other packages. removing zfs doesn't seem to have been well thought out.
*** Bug 2440156 has been marked as a duplicate of this bug. ***
FEDORA-2026-1f01cc9c24 (libvirt-11.6.0-3.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-1f01cc9c24
FEDORA-2026-1f01cc9c24 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-1f01cc9c24` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-1f01cc9c24 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I have inspect the new build and the git diff. Functional it looks working, but there was 2 lines removed to much. https://src.fedoraproject.org/rpms/libvirt/c/56f4c0a890c569be857627bd58888be871b9124d?branch=f43 line 790 about the remove of: Requires: /sbin/zfs Requires: /sbin/zpool Because of an working package this files are need and provided by the zfs developers. rpm -qp --requires libvirt-daemon-driver-storage-zfs-11.6.0-3.fc43.x86_64.rpm libc.so.6()(64bit) libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.4)(64bit) libc.so.6(GLIBC_ABI_DT_RELR)(64bit) libgcc_s.so.1()(64bit) libgcc_s.so.1(GCC_3.0)(64bit) libgcc_s.so.1(GCC_3.3.1)(64bit) libglib-2.0.so.0()(64bit) libvirt-daemon-driver-storage-core = 11.6.0-3.fc43 libvirt-libs = 11.6.0-3.fc43 libvirt.so.0()(64bit) libvirt.so.0(LIBVIRT_PRIVATE_11.6.0)(64bit) rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsZstd) <= 5.4.18-1 rtld(GNU_HASH) See the packages for Fedora 43: http://download.zfsonlinux.org/fedora/43/x86_64/zfs-2.4.0-1.fc43.x86_64.rpm less zfs-2.4.0-1.fc43.x86_64.rpm|grep /sbin/zfs -rwxr-xr-x 1 root root 154752 Dez 18 18:57 /sbin/zfs less zfs-2.4.0-1.fc43.x86_64.rpm|grep /sbin/zpool -rwxr-xr-x 1 root root 299200 Dez 18 18:57 /sbin/zpool
(In reply to Frank Büttner from comment #12) > I have inspect the new build and the git diff. > Functional it looks working, but there was 2 lines removed to much. > https://src.fedoraproject.org/rpms/libvirt/c/ > 56f4c0a890c569be857627bd58888be871b9124d?branch=f43 > line 790 about the remove of: > Requires: /sbin/zfs > Requires: /sbin/zpool > > Because of an working package this files are need and provided by the zfs > developers. That is not a mistake - it is required for compliance with Fedora packaging rules https://docs.fedoraproject.org/en-US/packaging-guidelines/#_package_dependencies "All package dependencies (build-time or runtime, regular, weak or otherwise) MUST ALWAYS be satisfiable within the official Fedora repositories." Users have to arrange for the ZFS userspace to be installed, whether that's via 3rd party RPMs or a custom install. Either way we cannot express a dependency on that.
In this case the "rules" breaks complete the system and the user experience. For example on removing of zfs the libvirt-daemon-driver-storage-zfs package will not be removed. This will breaks the package dependency model. So here the "rules" must be ignored for an stable system.
(In reply to Frank Büttner from comment #14) > In this case the "rules" breaks complete the system and the user experience. > For example on removing of zfs the libvirt-daemon-driver-storage-zfs package > will not be removed. > This will breaks the package dependency model. So here the "rules" must be > ignored for an stable system. That's just life when depending on software that is not provided as part of Fedora. We can't ship RPMs which have broken deps, due to the required packages not existing in Fedora repos. We could have simply stuck to the current situation where we fully disable ZFS on Fedora, but we re-enabled it without the deps as a favour to users who want to bring along their on ZFS userspace from outside Fedora.
FEDORA-2026-1f01cc9c24 (libvirt-11.6.0-3.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.