[libvirt] [RFC] proposal for libiscsi storage pool

Jiri Denemark jdenemar at redhat.com
Tue Jun 5 08:14:15 UTC 2018


On Tue, Jun 05, 2018 at 09:37:06 +0200, Michal Privoznik wrote:
> On 06/04/2018 05:54 PM, Clementine Hayat wrote:
> > Hi everybody!
> >
> > I am starting this thread to discuss a new storage pool backend for
> > iSCSI using libiSCSI.

Thanks a lot for working on this, I'm looking forward to switching to
the new pool.

> > There already is an iSCSI backend, however, it uses iscsiadm binary to
> > execute the desired operation. The binary can be spawned multiple
> > times during single execution of an API. This is suboptimal.
> > 
> > Moreover the iscsi storage pool is mapped by the kernel into a block
> > device in /dev/. Iscsiadm makes operations directly on that block
> > device. Libiscsi on the other hand is sending the commands directly to
> > a remote iscsi portal. According to that, to be able to use a storage
> > pool using libiscsi we have to implement the storage pool backend
> > entirely.
> > 
> > What we would have:
> > 
> > Pool XML using iscsiadm:
> > 
> > <pool type="iscsi" mode="host">
> 
> This sounds reasonable. However, I think for backwards compatibility we
> need to treat <pool type="iscsi"/> as mode="host". That is, if we don't
> parse any @mode, we must assume "host" and then we can format it into
> the XML back.

On the other hand, we could perhaps just introduce a new pool type,
something like

    <pool type='iscsi-direct'>...</pool>

which would match with VIR_STORAGE_POOL_ISCSI_DIRECT and avoid the black
magic of translating type="iscsi" to VIR_STORAGE_POOL_LIBISCSI or
VIR_STORAGE_POOL_ISCSI depending on the mode attribute. Not to mention
that old libvirt would just completely ignore the mode attribute, but it
would complain about unknown pool type.

Jirka




More information about the libvir-list mailing list