Bug 1240965
| Summary: | dependency on qemu while removing gluster | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Saro <saravanakumar.punith> |
| Component: | qemu | Assignee: | Fedora Virtualization Maintainers <virt-maint> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 25 | CC: | amit.shah, bengland, berrange, cfergeau, crobinso, dwmw2, humble.devassy, itamar, joe, jonathansteffan, kkeithle, lmohanty, mpillai, ndevos, pbonzini, rjones, rsawhill, sankarshan, saravanakumar.punith, sasundar, vbellur, virt-maint |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-01-16 14:21:12 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Saro
2015-07-08 09:13:31 UTC
qemu links against libgfapi.so from the glusterfs-api package. This makes it possible to support storage directly on Gluster volumes without the need to mount the volume, like "qemu ... -drive gluster://server/volume/vm.img ...". The dependency is the other way around, qemu depends on glusterfs-api, and if glusterfs-api gets uninstalled, qemu gets pulled with it. The same is true for installing qemu, glusterfs-api is a requirement and will get installed too. Some other projects that use libgfapi.so implement a plugin functionality (see Samba, NFS-Ganesha). This makes it possible to only install the plugins (and dependencies) that a user wants. For all I know, qemu does not offer the option for dynamically loaded plugins :-/ Moving this to the qemu component so that the maintainers can share their thoughts. Thanks Niels. <<The same is true for installing qemu, glusterfs-api is a requirement and will get installed too. If I am "not" interested in using glusterfs in qemu, should installing qemu still install glusterfs-api too? I think it is wrong. There is too much of inter-dependencies created here. qemu does have support for block driver modules, so we could make the gluster dep a subpackage. But I never did it since libvirt storage support _also_ has a dep on gluster, which can't be modularized. So most qemu/kvm users wouldn't really benefit since they are likely using libvirt anyways. But I'll add it to the todo list to investigate again (In reply to Cole Robinson from comment #3) > qemu does have support for block driver modules, so we could make the > gluster dep a subpackage. But I never did it since libvirt storage support > _also_ has a dep on gluster, which can't be modularized. So most qemu/kvm > users wouldn't really benefit since they are likely using libvirt anyways. > But I'll add it to the todo list to investigate again Thanks Cole! If somebody wishes to upgrade/remove glusterfs. They need to remove qemu,libvirt, boxes even if they are NOT using these packages. My humble request is to make the dependency ONLY if there is a need. As mentioned, the libvirt/boxes dep issue will take substantially more work... we need dynamic modules for libvirt's storage support. I opened an upstream libvirt bug to track that work: https://bugzilla.redhat.com/show_bug.cgi?id=1243001 cc'ing Vijay Bellur. I agree (bz 1194503), KVM should NOT have any hard dependency on Gluster being present, but should be able to utilize it (for libgfapi, for example), if it is present. That's why we have dynamically loadable shared libraries. This is consistent with creating leaner, smaller, less complicated Linux installs. We don't want to blow away running VMs that depend on Gluster by uninstalling Gluster, but it's not hard to tell whether there are such VMs running - they would have disks in their libvirt XML that reference libgfapi, yes? Still relevant with f24 Fedora 25+ now has qemu block drivers built as modules. qemu-system-x86 will still pull in gluster via qemu-block-gluster, but you can use the qemu-system-x86-core package to pull in qemu without any external block drivers. |