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