[libvirt] [RFC] proposal for libiscsi storage pool

[Daniel P. Berrangé]

On Tue, Jun 05, 2018 at 10:14:15AM +0200, Jiri Denemark wrote:
> 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.

I think we need to consider the bigger picture too - the idea of using
a userspace client vs kernel client applies to the RBD and GlusterFS
pools too. I'm not really convinced that adding new pool types for
each case makes sense.

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