Re: [Qemu-devel] [PATCH] This patch adds a new block driver : iSCSI

[Dor Laor <dlaor@redhat.com>]

On 09/15/2011 12:11 PM, Paolo Bonzini wrote:
> On 09/15/2011 10:48 AM, Dor Laor wrote:
>>> We need the same patch for NBD, so I wouldn't bother with the
>>> synchronous flush.
>>
>> It seems to me that using a qemu external initiator/target pairs like
>> Orit's original design in
>> http://wiki.qemu.org/Features/LiveBlockMigration#ISCSI_for_non_shared_storage
>>
>> would be a simpler (in terms of qemu code..) and flexible solution.
>
> Yes, it would be simpler for QEMU because everything is done outside.
>
> However, iSCSI is a complex protocol and a complex suite of tools. With
> a simpler set of tools such as qemu-nbd/nbd, you can for example tunnel
> data over the libvirt connection. Possibly with encryption. Also, with
> iSCSI you're tied to raw, while qemu-nbd lets you use qcow2.

My main motivation for external iScsi is to provide qemu operations w/ 
non shared storage. Things like streaming an image w/o shared storage or 
block live migration can be done where the src host exposes iscsi target 
and the destination is the initiator. In case of qcow2, every snapshot 
in the chain should be exposed as a separate LUN. The idea is to ignore 
the data in the guest image and treat it as opaque.

>
> iSCSI could be a better choice if everything in the QEMU block layer was
> done in terms of SCSI. However, we're a far cry from that.
>
>> I agree that embedding the iscsi initiation in qemu can simplify the end
>> user life but since this scenario is expected to be used by higher level
>> software it's not relevant here. The risk is to have to maintain more
>> code that won't be as general as the tgtd/lio solutions out there.
>
> I'm not sure I understand. You say "embedding the iSCSI initiator in
> qemu can simplify the end user life" but "the risk is to have to
> maintain [another iSCSI target]". I don't think anybody proposed adding
> an iSCSI target to QEMU (in fact tcm_vhost would even let you use lio
> instead of QEMU's SCSI target code!). Only an iSCSI initiator which is
> not much code because it's just a wrapper for libiscsi.
>
> In general, I'm not sure that libiscsi (instead of the in-kernel iSCSI
> initiator) is by definition a bad choice in high-end set-ups. If you
> want to do SCSI passthrough, it's likely better to use libiscsi rather
> than using the in-kernel initiator together with scsi-generic
> (scsi-generic sucks; bsg is better but also a useless level of
> indirection IMO).
>
> Perhaps Ronnie has rough performance numbers comparing in-kernel iSCSI
> with libiscsi?
>
> Paolo