From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42908) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XNUmp-0004no-U2 for qemu-devel@nongnu.org; Fri, 29 Aug 2014 18:36:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XNUmj-0005Cc-Pe for qemu-devel@nongnu.org; Fri, 29 Aug 2014 18:36:51 -0400 Received: from mx1.redhat.com ([209.132.183.28]:5417) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XNUmj-0005CS-GM for qemu-devel@nongnu.org; Fri, 29 Aug 2014 18:36:45 -0400 Message-ID: <54010079.8050100@redhat.com> Date: Fri, 29 Aug 2014 15:36:41 -0700 From: Andy Grover MIME-Version: 1.0 References: <20140829172218.GD16755@irqsave.net> <5400C896.2040600@redhat.com> <20140829185121.GA31376@irqsave.net> In-Reply-To: <20140829185121.GA31376@irqsave.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: =?ISO-8859-1?Q?Beno=EEt_Canet?= Cc: kwolf@redhat.com, pbonzini@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com 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 ha= ndler > would mean that there would be _one_ QMP socket opened > (by mean of wonderfull QEMU modules static variables :) to control mult= iple block devices > exported. > > So I think the configuration passed must be done before an individual o= pen occurs: > being global to the .so implementing the tcmu-runner handler. > > But I don't see how to do it with the current API. This discussion leads me to think we need to step back and discuss our=20 requirements. I am looking for flexible backstores for SCSI-based=20 fabrics, with as little new code as possible. I think you are looking=20 for a way to export QEMU block devices over iSCSI and other fabrics? I don't think making a LIO userspace handler into basically a=20 full-fledged secondary QEMU server instance is the way to go. What I=20 think better serves your requirements is to enable QEMU to configure LIO. 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. Whether a volume is exported over iSCSI or FCoE or not shouldn't affect=20 how it is managed. QMP commands should go to the single QEMU server,=20 which can then optionally configure LIO to export the volume. That=20 leaves us with the issue that we'd need to arbitrate access to the=20 backing file if taking a streaming snapshot (qemu and tcmu-runner=20 processes both accessing the img), but that should be straightforward,=20 or at least work that can be done in a second phase of development. Thoughts? Regards -- Andy p.s. offline Monday.