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

[Pino Toscano]

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
-------------- 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/f1c058a5/attachment.sig>