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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
