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
