Re: [RFC] proposal for libiscsi storage pool

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Jun 05, 2018 at 09:31:09 +0100, Daniel P. Berrangé wrote:
> 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.

Hmm, good point. So in that case, I'd just recommend some kind of
predictable name for VIR_STORAGE_POOL_ item, such as adding a _DIRECT
suffix and use VIR_STORAGE_POOL_ISCSI_DIRECT (and
VIR_STORAGE_POOL_*_DIRECT for other pool types) rather than
VIR_STORAGE_POOL_LIBISCSI from which the connection to the pool
type/mode in the XML is not very clear.

Jirka

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux