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

Pino Toscano ptoscano at redhat.com
Fri Jan 10 16:21:23 UTC 2020


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20200110/261181cb/attachment.sig>


More information about the Libguestfs mailing list