[PATCH Fedora libguestfs] Don't depend on libvirt-daemon-kvm monolith.
libguestfs usually needs qemu. However it only requires an emulator for the same architecture, not for all architectures. libvirt-daemon-kvm pulls in qemu which pulls in emulators for all architectures, as well as a bunch of other stuff we don't need at all like network interface support and nwfilter. There are no Fedora TCG-only arches, so drop the conditional section. I also made support for storage backends "Recommends" so that people can get rid of things like Gluster if they want. --- libguestfs.spec | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/libguestfs.spec b/libguestfs.spec index 0d32ef0..71f97c6 100644 --- a/libguestfs.spec +++ b/libguestfs.spec @@ -211,12 +211,16 @@ Requires: fuse # For core disk-create API. Requires: /usr/bin/qemu-img -# For libvirt backend. -%ifarch %{ix86} x86_64 %{arm} aarch64 -Requires: libvirt-daemon-kvm >= 0.10.2-3 -%else +# For qemu direct and libvirt backends. +Requires: qemu-kvm-core +Requires: libvirt-daemon-driver-qemu +Recommends: libvirt-daemon-driver-storage-disk +Recommends: libvirt-daemon-driver-storage-gluster +Recommends: libvirt-daemon-driver-storage-iscsi +Recommends: libvirt-daemon-driver-storage-logical +Recommends: libvirt-daemon-driver-storage-rbd +Recommends: libvirt-daemon-driver-storage-scsi Requires: libvirt-daemon-qemu >= 0.10.2-3 -%endif Recommends: libvirt-daemon-config-network Requires: selinux-policy >= 3.11.1-63 -- 2.24.1
On Friday, 10 January 2020 15:05:33 CET Richard W.M. Jones wrote:
libguestfs usually needs qemu. However it only requires an emulator for the same architecture, not for all architectures. libvirt-daemon-kvm pulls in qemu which pulls in emulators for all architectures, as well as a bunch of other stuff we don't need at all like network interface support and nwfilter.
There are no Fedora TCG-only arches, so drop the conditional section.
I also made support for storage backends "Recommends" so that people can get rid of things like Gluster if they want. --- libguestfs.spec | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/libguestfs.spec b/libguestfs.spec index 0d32ef0..71f97c6 100644 --- a/libguestfs.spec +++ b/libguestfs.spec @@ -211,12 +211,16 @@ Requires: fuse # For core disk-create API. Requires: /usr/bin/qemu-img
-# For libvirt backend. -%ifarch %{ix86} x86_64 %{arm} aarch64 -Requires: libvirt-daemon-kvm >= 0.10.2-3 -%else +# For qemu direct and libvirt backends. +Requires: qemu-kvm-core +Requires: libvirt-daemon-driver-qemu
This is OK.
+Recommends: libvirt-daemon-driver-storage-disk +Recommends: libvirt-daemon-driver-storage-gluster +Recommends: libvirt-daemon-driver-storage-iscsi +Recommends: libvirt-daemon-driver-storage-logical +Recommends: libvirt-daemon-driver-storage-rbd +Recommends: libvirt-daemon-driver-storage-scsi
This is not needed, libguestfs does not need these libvirt drivers.
Requires: libvirt-daemon-qemu >= 0.10.2-3
This still requires qemu, which in turns requires all the qemu-system-* packages, so it has to go too. In addition to that, we need at least the libvirt secret driver, so require also libvirt-daemon-driver-secret. -- Pino Toscano
On Fri, Jan 10, 2020 at 03:10:51PM +0100, Pino Toscano wrote:
Requires: libvirt-daemon-qemu >= 0.10.2-3
This still requires qemu, which in turns requires all the qemu-system-* packages, so it has to go too.
Sorry this line was left in by accident. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top
On Fri, Jan 10, 2020 at 03:10:51PM +0100, Pino Toscano wrote:
On Friday, 10 January 2020 15:05:33 CET Richard W.M. Jones wrote:
libguestfs usually needs qemu. However it only requires an emulator for the same architecture, not for all architectures. libvirt-daemon-kvm pulls in qemu which pulls in emulators for all architectures, as well as a bunch of other stuff we don't need at all like network interface support and nwfilter.
There are no Fedora TCG-only arches, so drop the conditional section.
I also made support for storage backends "Recommends" so that people can get rid of things like Gluster if they want. --- libguestfs.spec | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/libguestfs.spec b/libguestfs.spec index 0d32ef0..71f97c6 100644 --- a/libguestfs.spec +++ b/libguestfs.spec @@ -211,12 +211,16 @@ Requires: fuse # For core disk-create API. Requires: /usr/bin/qemu-img
-# For libvirt backend. -%ifarch %{ix86} x86_64 %{arm} aarch64 -Requires: libvirt-daemon-kvm >= 0.10.2-3 -%else +# For qemu direct and libvirt backends. +Requires: qemu-kvm-core +Requires: libvirt-daemon-driver-qemu
This is OK.
+Recommends: libvirt-daemon-driver-storage-disk +Recommends: libvirt-daemon-driver-storage-gluster +Recommends: libvirt-daemon-driver-storage-iscsi +Recommends: libvirt-daemon-driver-storage-logical +Recommends: libvirt-daemon-driver-storage-rbd +Recommends: libvirt-daemon-driver-storage-scsi
This is not needed, libguestfs does not need these libvirt drivers.
Was this perhaps supposed to be qemu-block-{curl,gluster,iscsi,rbd,etc) to get the QEMU block drivers ?
Requires: libvirt-daemon-qemu >= 0.10.2-3
This still requires qemu, which in turns requires all the qemu-system-* packages, so it has to go too.
In addition to that, we need at least the libvirt secret driver, so require also libvirt-daemon-driver-secret.
-- Pino Toscano
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs
Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Friday, 10 January 2020 15:18:38 CET Daniel P. Berrangé wrote:
On Fri, Jan 10, 2020 at 03:10:51PM +0100, Pino Toscano wrote:
On Friday, 10 January 2020 15:05:33 CET Richard W.M. Jones wrote:
+Recommends: libvirt-daemon-driver-storage-disk +Recommends: libvirt-daemon-driver-storage-gluster +Recommends: libvirt-daemon-driver-storage-iscsi +Recommends: libvirt-daemon-driver-storage-logical +Recommends: libvirt-daemon-driver-storage-rbd +Recommends: libvirt-daemon-driver-storage-scsi
This is not needed, libguestfs does not need these libvirt drivers.
Was this perhaps supposed to be qemu-block-{curl,gluster,iscsi,rbd,etc) to get the QEMU block drivers ?
Possibly: libguestfs can access remote disks. I do not think it is a common feature though, so in case I'd add the qemu block drivers as suggests (not recommends), so they are not installed by default, and users know somehow that installing them enables extra features. -- Pino Toscano
On Fri, Jan 10, 2020 at 02:05:33PM +0000, Richard W.M. Jones wrote:
libguestfs usually needs qemu. However it only requires an emulator for the same architecture, not for all architectures. libvirt-daemon-kvm pulls in qemu which pulls in emulators for all architectures, as well as a bunch of other stuff we don't need at all like network interface support and nwfilter.
There are no Fedora TCG-only arches, so drop the conditional section.
I also made support for storage backends "Recommends" so that people can get rid of things like Gluster if they want. --- libguestfs.spec | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/libguestfs.spec b/libguestfs.spec index 0d32ef0..71f97c6 100644 --- a/libguestfs.spec +++ b/libguestfs.spec @@ -211,12 +211,16 @@ Requires: fuse # For core disk-create API. Requires: /usr/bin/qemu-img
-# For libvirt backend. -%ifarch %{ix86} x86_64 %{arm} aarch64 -Requires: libvirt-daemon-kvm >= 0.10.2-3 -%else +# For qemu direct and libvirt backends. +Requires: qemu-kvm-core +Requires: libvirt-daemon-driver-qemu
Do you use the libvirt "secret" APIs at all (disk encryption, network disk auth passwords) ? If so you will need "libvirt-daemon-driver-secret" too. How about any other libvirt sub-driver APIs ? Networking ? Host dev, etc ?
+Recommends: libvirt-daemon-driver-storage-disk +Recommends: libvirt-daemon-driver-storage-gluster +Recommends: libvirt-daemon-driver-storage-iscsi +Recommends: libvirt-daemon-driver-storage-logical +Recommends: libvirt-daemon-driver-storage-rbd +Recommends: libvirt-daemon-driver-storage-scsi Requires: libvirt-daemon-qemu >= 0.10.2-3
You need to cull this last existing line too
-%endif Recommends: libvirt-daemon-config-network Requires: selinux-policy >= 3.11.1-63
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> with the line culled Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Fri, Jan 10, 2020 at 02:15:10PM +0000, Daniel P. Berrangé wrote:
Do you use the libvirt "secret" APIs at all (disk encryption, network disk auth passwords) ? If so you will need "libvirt-daemon-driver-secret" too. How about any other libvirt sub-driver APIs ? Networking ? Host dev, etc ?
The full list of APIs we use is attached, assuming I got my regexp correct.
+Recommends: libvirt-daemon-driver-storage-disk +Recommends: libvirt-daemon-driver-storage-gluster +Recommends: libvirt-daemon-driver-storage-iscsi +Recommends: libvirt-daemon-driver-storage-logical +Recommends: libvirt-daemon-driver-storage-rbd +Recommends: libvirt-daemon-driver-storage-scsi
In his response Pino questioned if we need these at all. I may not understand exactly what they do, but we *do* use libvirt XML containing disk elements to refer to disks, as well as elements referring to gluster, iscsi, ceph, etc.
Requires: libvirt-daemon-qemu >= 0.10.2-3
You need to cull this last existing line too
Yes, this was left over by accident. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW
On Fri, Jan 10, 2020 at 02:26:35PM +0000, Richard W.M. Jones wrote:
On Fri, Jan 10, 2020 at 02:15:10PM +0000, Daniel P. Berrangé wrote:
Do you use the libvirt "secret" APIs at all (disk encryption, network disk auth passwords) ? If so you will need "libvirt-daemon-driver-secret" too. How about any other libvirt sub-driver APIs ? Networking ? Host dev, etc ?
The full list of APIs we use is attached, assuming I got my regexp correct.
+Recommends: libvirt-daemon-driver-storage-disk +Recommends: libvirt-daemon-driver-storage-gluster +Recommends: libvirt-daemon-driver-storage-iscsi +Recommends: libvirt-daemon-driver-storage-logical +Recommends: libvirt-daemon-driver-storage-rbd +Recommends: libvirt-daemon-driver-storage-scsi
In his response Pino questioned if we need these at all. I may not understand exactly what they do, but we *do* use libvirt XML containing disk elements to refer to disks, as well as elements referring to gluster, iscsi, ceph, etc.
These are specific impls of the libvirt storage pool APIs. If you're only usng domain <disk>s which directly reference gluster/iscsi/etc, you don't need the storage pool APIs. If you're using domain <disk>s which use type=volume, then you'll need the storage pool APIs & any impls that are relevant
virStoragePoolFree ( virStoragePoolGetInfo ( virStoragePoolLookupByName ( virStorageVolFree ( virStorageVolGetInfo ( virStorageVolGetPath ( virStorageVolLookupByName (
So something in libguestfs is using storage pools, which would mean you want libvirt-daemon-driver-storage-core, and one or more of the pool impls that you use. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Friday, 10 January 2020 15:39:21 CET Daniel P. Berrangé wrote:
On Fri, Jan 10, 2020 at 02:26:35PM +0000, Richard W.M. Jones wrote:
On Fri, Jan 10, 2020 at 02:15:10PM +0000, Daniel P. Berrangé wrote:
Do you use the libvirt "secret" APIs at all (disk encryption, network disk auth passwords) ? If so you will need "libvirt-daemon-driver-secret" too. How about any other libvirt sub-driver APIs ? Networking ? Host dev, etc ?
The full list of APIs we use is attached, assuming I got my regexp correct.
+Recommends: libvirt-daemon-driver-storage-disk +Recommends: libvirt-daemon-driver-storage-gluster +Recommends: libvirt-daemon-driver-storage-iscsi +Recommends: libvirt-daemon-driver-storage-logical +Recommends: libvirt-daemon-driver-storage-rbd +Recommends: libvirt-daemon-driver-storage-scsi
In his response Pino questioned if we need these at all. I may not understand exactly what they do, but we *do* use libvirt XML containing disk elements to refer to disks, as well as elements referring to gluster, iscsi, ceph, etc.
These are specific impls of the libvirt storage pool APIs.
If you're only usng domain <disk>s which directly reference gluster/iscsi/etc, you don't need the storage pool APIs.
If you're using domain <disk>s which use type=volume, then you'll need the storage pool APIs & any impls that are relevant
The way we tell libvirt to access disks in remote protocols is using <disk> with type=file, type=block, and type=network. See construct_libvirt_xml_disk() in lib/launch-libvirt.c: https://github.com/libguestfs/libguestfs/blob/c9543de73d264943fef88f5e53403b... AFAICT that way does not use the storage pool drivers.
virStoragePoolFree ( virStoragePoolGetInfo ( virStoragePoolLookupByName ( virStorageVolFree ( virStorageVolGetInfo ( virStorageVolGetPath ( virStorageVolLookupByName (
So something in libguestfs is using storage pools, which would mean you want libvirt-daemon-driver-storage-core, and one or more of the pool impls that you use.
This is when libguestfs is told to open a libvirt domain, and the disks are specified as volumes in a local fs pool: libguestfs then gets the actual paths of the volumes. See filename_from_pool() in lib/libvirt-domain.c: https://github.com/libguestfs/libguestfs/blob/c9543de73d264943fef88f5e53403b... -- Pino Toscano
On Fri, Jan 10, 2020 at 05:21:23PM +0100, Pino Toscano wrote:
On Friday, 10 January 2020 15:39:21 CET Daniel P. Berrangé wrote:
On Fri, Jan 10, 2020 at 02:26:35PM +0000, Richard W.M. Jones wrote:
On Fri, Jan 10, 2020 at 02:15:10PM +0000, Daniel P. Berrangé wrote:
Do you use the libvirt "secret" APIs at all (disk encryption, network disk auth passwords) ? If so you will need "libvirt-daemon-driver-secret" too. How about any other libvirt sub-driver APIs ? Networking ? Host dev, etc ?
The full list of APIs we use is attached, assuming I got my regexp correct.
+Recommends: libvirt-daemon-driver-storage-disk +Recommends: libvirt-daemon-driver-storage-gluster +Recommends: libvirt-daemon-driver-storage-iscsi +Recommends: libvirt-daemon-driver-storage-logical +Recommends: libvirt-daemon-driver-storage-rbd +Recommends: libvirt-daemon-driver-storage-scsi
In his response Pino questioned if we need these at all. I may not understand exactly what they do, but we *do* use libvirt XML containing disk elements to refer to disks, as well as elements referring to gluster, iscsi, ceph, etc.
These are specific impls of the libvirt storage pool APIs.
If you're only usng domain <disk>s which directly reference gluster/iscsi/etc, you don't need the storage pool APIs.
If you're using domain <disk>s which use type=volume, then you'll need the storage pool APIs & any impls that are relevant
The way we tell libvirt to access disks in remote protocols is using <disk> with type=file, type=block, and type=network. See construct_libvirt_xml_disk() in lib/launch-libvirt.c: https://github.com/libguestfs/libguestfs/blob/c9543de73d264943fef88f5e53403b...
AFAICT that way does not use the storage pool drivers.
YEs, that is correct.
virStoragePoolFree ( virStoragePoolGetInfo ( virStoragePoolLookupByName ( virStorageVolFree ( virStorageVolGetInfo ( virStorageVolGetPath ( virStorageVolLookupByName (
So something in libguestfs is using storage pools, which would mean you want libvirt-daemon-driver-storage-core, and one or more of the pool impls that you use.
This is when libguestfs is told to open a libvirt domain, and the disks are specified as volumes in a local fs pool: libguestfs then gets the actual paths of the volumes. See filename_from_pool() in lib/libvirt-domain.c: https://github.com/libguestfs/libguestfs/blob/c9543de73d264943fef88f5e53403b...
Ok, for that you will need storage pools, however, if there really is such a domain present on the host, you can reasonably assume that the user has already installed the libvirt storage pool driver. So libguestfs itself can avoid the storage driver dep. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
On Friday, 10 January 2020 17:34:27 CET Daniel P. Berrangé wrote:
virStoragePoolFree ( virStoragePoolGetInfo ( virStoragePoolLookupByName ( virStorageVolFree ( virStorageVolGetInfo ( virStorageVolGetPath ( virStorageVolLookupByName (
So something in libguestfs is using storage pools, which would mean you want libvirt-daemon-driver-storage-core, and one or more of the pool impls that you use.
This is when libguestfs is told to open a libvirt domain, and the disks are specified as volumes in a local fs pool: libguestfs then gets the actual paths of the volumes. See filename_from_pool() in lib/libvirt-domain.c: https://github.com/libguestfs/libguestfs/blob/c9543de73d264943fef88f5e53403b...
Ok, for that you will need storage pools, however, if there really is such a domain present on the host, you can reasonably assume that the user has already installed the libvirt storage pool driver. So libguestfs itself can avoid the storage driver dep.
Considering we support only file volumes, would be recommend/suggest libvirt-daemon-driver-storage-core a safe choice? -- Pino Toscano
On Fri, Jan 10, 2020 at 05:41:54PM +0100, Pino Toscano wrote:
On Friday, 10 January 2020 17:34:27 CET Daniel P. Berrangé wrote:
virStoragePoolFree ( virStoragePoolGetInfo ( virStoragePoolLookupByName ( virStorageVolFree ( virStorageVolGetInfo ( virStorageVolGetPath ( virStorageVolLookupByName (
So something in libguestfs is using storage pools, which would mean you want libvirt-daemon-driver-storage-core, and one or more of the pool impls that you use.
This is when libguestfs is told to open a libvirt domain, and the disks are specified as volumes in a local fs pool: libguestfs then gets the actual paths of the volumes. See filename_from_pool() in lib/libvirt-domain.c: https://github.com/libguestfs/libguestfs/blob/c9543de73d264943fef88f5e53403b...
Ok, for that you will need storage pools, however, if there really is such a domain present on the host, you can reasonably assume that the user has already installed the libvirt storage pool driver. So libguestfs itself can avoid the storage driver dep.
Considering we support only file volumes, would be recommend/suggest libvirt-daemon-driver-storage-core a safe choice?
Yeah that's reasonable. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
participants (3)
-
Daniel P. Berrangé -
Pino Toscano -
Richard W.M. Jones