From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4AaE-0004OF-R4 for qemu-devel@nongnu.org; Thu, 15 Sep 2011 07:58:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R4AaD-0000oU-O2 for qemu-devel@nongnu.org; Thu, 15 Sep 2011 07:58:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39118) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R4AaD-0000oK-Fm for qemu-devel@nongnu.org; Thu, 15 Sep 2011 07:58:21 -0400 Message-ID: <4E71E854.10302@redhat.com> Date: Thu, 15 Sep 2011 13:58:12 +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> <4E71C146.6070406@redhat.com> <4E71E4B2.9060304@redhat.com> In-Reply-To: <4E71E4B2.9060304@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 01:42 PM, Dor Laor wrote: >> >> 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. Then you need an iSCSI *target* that understands qcow2, like qemu-nbd but for iSCSI... that's exactly the thing you were worried about implementing. (Of course you could use qemu-nbd and expose /dev/nbd* via iSCSI, but it starts looking like an exercise in adding layers of indirections! :)). Paolo