[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dor Laor
Subject: Re: [Qemu-devel] [PATCH] This patch adds a new block driver : iSCSI
Date: Thu, 15 Sep 2011 14:42:42 +0300
User-agent: Mozilla/5.0 (X11; Linux i686; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2

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

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]