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.
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