8:05 a.m.
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
8:10 a.m.
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
8:18 a.m.
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
8:18 a.m.
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(a)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 :|
8:23 a.m.
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
8:15 a.m.
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(a)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 :|
8:26 a.m.
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
8:39 a.m.
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 :|
10:21 a.m.
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/c9543de73d264943fef88f5e534...
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/c9543de73d264943fef88f5e534...
--
Pino Toscano
10:34 a.m.
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/c9543de73d264943fef88f5e534...
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/c9543de73d264943fef88f5e534...
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 :|
10:41 a.m.
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/c9543de73d264943fef88f5e534...
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
10:43 a.m.
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/c9543de73d264943fef88f5e534...
>
> 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 :|
1659
days inactive
1659
days old
11 comments
3 participants
participants (3)
-
Daniel P. Berrangé -
Pino Toscano -
Richard W.M. Jones