From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34475) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R47zD-0002kt-MV for qemu-devel@nongnu.org; Thu, 15 Sep 2011 05:12:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R47zC-0001Na-AD for qemu-devel@nongnu.org; Thu, 15 Sep 2011 05:11:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35359) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R47zC-0001NE-31 for qemu-devel@nongnu.org; Thu, 15 Sep 2011 05:11:58 -0400 Message-ID: <4E71C146.6070406@redhat.com> Date: Thu, 15 Sep 2011 11:11:34 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1315628610-28222-1-git-send-email-ronniesahlberg@gmail.com> <1315628610-28222-2-git-send-email-ronniesahlberg@gmail.com> <20110912091408.GA3465@stefanha-thinkpad.localdomain> <4E71956B.6030902@redhat.com> <4E71BBE3.5000207@redhat.com> In-Reply-To: <4E71BBE3.5000207@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] This patch adds a new block driver : iSCSI List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dlaor@redhat.com Cc: kwolf@redhat.com, Stefan Hajnoczi , qemu-devel@nongnu.org, fujita.tomonori@lab.ntt.co.jp, Orit Wasserman , Ronnie Sahlberg , hch@lst.de 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