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

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

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

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/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.
Considering we support only file volumes, would be recommend/suggest
libvirt-daemon-driver-storage-core a safe choice?

-- 
Pino Toscano