[libvirt] [RFC] proposal for libiscsi storage pool

[Michal Privoznik]

On 06/05/2018 10:14 AM, 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 don't see much problem with old libvirt ignoring @mode attribute.
Storage pools are not something we migrate back and forth like domains.
Sure, there's always the case of downgrading libvirt, but, that means
being forward compatible actually. I mean, any new element we add to XML
is not parsed by older libvirt.

Michal