From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57320) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOBuG-0008Gm-BG for qemu-devel@nongnu.org; Sun, 31 Aug 2014 16:39:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XOBuB-0005bf-GU for qemu-devel@nongnu.org; Sun, 31 Aug 2014 16:39:24 -0400 Received: from lputeaux-656-01-25-125.w80-12.abo.wanadoo.fr ([80.12.84.125]:55816 helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XOBuB-0005bN-9y for qemu-devel@nongnu.org; Sun, 31 Aug 2014 16:39:19 -0400 Date: Sun, 31 Aug 2014 22:38:29 +0200 From: =?iso-8859-1?Q?Beno=EEt?= Canet Message-ID: <20140831203828.GA23970@irqsave.net> References: <20140829172218.GD16755@irqsave.net> <20140830144641.GM14001@redhat.com> <20140830155343.GA2212@irqsave.net> <20140830160212.GH1302@redhat.com> <54037F82.9050209@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <54037F82.9050209@redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] tcmu-runner and QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Andy Grover Cc: =?iso-8859-1?Q?Beno=EEt?= Canet , kwolf@redhat.com, qemu-devel@nongnu.org, "Richard W.M. Jones" , stefanha@redhat.com, pbonzini@redhat.com The Sunday 31 Aug 2014 =E0 13:03:14 (-0700), Andy Grover wrote : > On 08/30/2014 09:02 AM, Richard W.M. Jones wrote: > >On Sat, Aug 30, 2014 at 05:53:43PM +0200, Beno=EEt Canet wrote: > >>If the cloud provider want to be able to boot QCOW2 or QED images on > >>bare metal machines he will need to export QCOW2 or QED images on > >>the network. > >> > >>So far only qemu-nbd allows to do this and it is neither well > >>performing nor really convenient to boot on a bare metal machine. > > > >So I think what you want is a `qemu-iscsi'? ie. the same as qemu-nbd, > >but with an iSCSI frontend (to replace the NBD server). >=20 > You want qemu to be able to issue SCSI commands over iSCSI? I thought q= emu > used libiscsi for this, to be the initiator. What Benoit and I have bee= n > discussing is the other side, enabling qemu to configure LIO to handle > requests from other initiators (either VMs or iron) over iSCSI or FCoE,= but > backed by qcow2 disk images. The problem being LIO doesn't speak qcow2 = yet. >=20 > >I guess so. Are you planning to integrate bits of LIO into qemu, or > >bits of qemu into LIO? >=20 > My current thinking is 1) enable qemu to configure the LIO kernel targe= t > (it's all straightforward via configfs, but add a nice library to qemu = to > hide the details) and 2) enable LIO to use qcow2 and other formats besi= des > raw images to back exported LUNs. This is where the LIO userspace > passthrough and tcmu-runner come in, because we want to do this in > userspace, not as kernel code, so we have to pass SCSI commands up to a > userspace helper daemon. >=20 > >The latter has been tried various times, without much success. See > >the many examples of people trying to make the qemu block driver code > >into a separate library, and failing. >=20 The problem with QEMU block drivers is that they are using either corouti= nes or QEMU custom AIO callbacks so reusing them without the block layer is not doable. For the QEMU block layer as a whole it maintains some linked lists of blo= ck devices states or similar stuff as static global variables. (See https://github.com/qemu/qemu/blob/master/block.c#L96) So having more than one instance of the block layer running is not doable= . I am not aware of anyone successfull in turning it into a proper .so. Extracting into a binary acting as an nbd target was done with qemu-nbd t= hough. Best regards Beno=EEt > What's been the sticking point? >=20 > Regards -- Andy >=20 >=20