From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50944) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XNUwy-0008GG-PN for qemu-devel@nongnu.org; Fri, 29 Aug 2014 18:47:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XNUws-0001CX-Jj for qemu-devel@nongnu.org; Fri, 29 Aug 2014 18:47:20 -0400 Received: from lputeaux-656-01-25-125.w80-12.abo.wanadoo.fr ([80.12.84.125]:57057 helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XNUws-0001CR-DX for qemu-devel@nongnu.org; Fri, 29 Aug 2014 18:47:14 -0400 Date: Sat, 30 Aug 2014 00:46:27 +0200 From: =?iso-8859-1?Q?Beno=EEt?= Canet Message-ID: <20140829224627.GA32561@irqsave.net> References: <20140829172218.GD16755@irqsave.net> <5400C896.2040600@redhat.com> <20140829185121.GA31376@irqsave.net> <54010079.8050100@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <54010079.8050100@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, stefanha@redhat.com, pbonzini@redhat.com The Friday 29 Aug 2014 =E0 15:36:41 (-0700), Andy Grover wrote : > On 08/29/2014 11:51 AM, Beno=EEt Canet wrote: > >QMP is just a way to control QEMU via a socket: it is not particularly= block related. > > > >On the other hand bringing the whole block layers into a tcmu-runner h= andler > >would mean that there would be _one_ QMP socket opened > >(by mean of wonderfull QEMU modules static variables :) to control mul= tiple block devices > >exported. > > > >So I think the configuration passed must be done before an individual = open occurs: > >being global to the .so implementing the tcmu-runner handler. > > > >But I don't see how to do it with the current API. >=20 > This discussion leads me to think we need to step back and discuss our > requirements. I am looking for flexible backstores for SCSI-based fabri= cs, > with as little new code as possible. > I think you are looking for a way to > export QEMU block devices over iSCSI and other fabrics? true >=20 > I don't think making a LIO userspace handler into basically a full-fled= ged > secondary QEMU server instance is the way to go. What I think better se= rves > your requirements is to enable QEMU to configure LIO. Ok as long as there is an efficient way for QEMU to process LIO requests. >=20 > In a previous email you wrote: > >Another reason to do this is that the QEMU block layer brings > >features like taking snapshots or streaming snaphots that a cloud > >provider would want to keep while exporting QCOW2 as ISCSI or FCOE. >=20 > Whether a volume is exported over iSCSI or FCoE or not shouldn't affect= how > it is managed. QMP commands should go to the single QEMU server, which = can > then optionally configure LIO to export the volume. That leaves us with= the > issue that we'd need to arbitrate access to the backing file if taking = a > streaming snapshot (qemu and tcmu-runner processes both accessing the i= mg), > but that should be straightforward, or at least work that can be done i= n a > second phase of development. That makes sense that QEMU trigger the LIO export by itself because it wi= ll be easier to integrate this feature into libvirt or another management stack= . Best regards Beno=EEt >=20 > Thoughts? >=20 > Regards -- Andy >=20 > p.s. offline Monday.