On Tue, Jun 05, 2018 at 09:31:09 +0100, Daniel Berrange 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. For 'gluster' we have the native pool type which uses the userspace client library and also we support using 'glusterfs' through the 'netfs' driver which mounts it on the host [1]. The difference here is that with iscsi we have a separate driver now and this would mean to have a different one, but it would not be much different from the gluster/glusterfs [2] scenario. [1] Glusterfs is a FUSE implementation, so it is technicaly userspace as well ... [2] glusterfs is generally the package name for the FUSE client
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
