[Libguestfs] [PATCH Fedora libguestfs] Don't depend on libvirt-daemon-kvm monolith.

[Daniel P. Berrangé]

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/c9543de73d264943fef88f5e53403bbe32917b01/lib/launch-libvirt.c#L1372
> 
> 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/c9543de73d264943fef88f5e53403bbe32917b01/lib/libvirt-domain.c#L893

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 :|