Hi everybody!
I am starting this thread to discuss a new storage pool backend for
iSCSI using libiSCSI.
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">
<name>virtimages</name>
<source>
<host name="iscsi.example.com"/>
<device path="iqn.2013-06.com.example:iscsi-pool"/>
<auth type='chap' username='myuser'>
<secret usage='libvirtiscsi'/>
</auth>
</source>
<target>
<path>/dev/disk/by-path</path>
</target>
</pool>
Pool XML using libiscsi:
<pool type="iscsi" mode="direct">
<name>virtimages</name>
<source>
<host name="iscsi.example.com"/>
<device path="iqn.2013-06.com.example:iscsi-pool"/>
<auth type='chap' username='myuser'>
<secret usage='libvirtiscsi'/>
</auth>
</source>
</pool>
The change that occurs is having a direct mode that will lead to the
libiscsi backend and the host mode that will lead to the actual
backend using iscsiadm.
To tie the backend to the front was thinking about adding something
like VIR_STORAGE_POOL_LIBISCSI to storage_conf.
About the domain XML only accept:
<disk type='volume' device='disk'>
<driver name='qemu' type='raw'/>
<source pool='iscsi-pool' volume='unit:0:0:2'
mode='direct'/>
<target dev='vdc' bus='virtio'/>
</disk>
would be great using a switch case on VIR_STORAGE_POOL_LIBISCSI inside
domain_conf.
Best regards,
--
Clementine Hayat