From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55056) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XNR49-0004IE-EW for qemu-devel@nongnu.org; Fri, 29 Aug 2014 14:38:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XNR3z-00036m-6c for qemu-devel@nongnu.org; Fri, 29 Aug 2014 14:38:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41526) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XNR3y-00036T-Uy for qemu-devel@nongnu.org; Fri, 29 Aug 2014 14:38:19 -0400 Message-ID: <5400C896.2040600@redhat.com> Date: Fri, 29 Aug 2014 11:38:14 -0700 From: Andy Grover MIME-Version: 1.0 References: <20140829172218.GD16755@irqsave.net> In-Reply-To: <20140829172218.GD16755@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?= , qemu-devel@nongnu.org Cc: kwolf@redhat.com, pbonzini@redhat.com, stefanha@redhat.com On 08/29/2014 10:22 AM, Beno=EEt Canet wrote: > The truth is that QEMU block drivers don't know how to do much on their= own > so we probably must bring the whole QEMU block layer in a tcmu-runner = handler plugin. Woah! Really? ok... > 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 kee= p while exporting > QCOW2 as ISCSI or FCOE. > > Doing these operations is usually done by passing something like > "--qmp tcp:localhost,4444,server,nowait" as a QEMU command line argumen= t then > connecting on this JSON processing socket then send orders to QEMU. The LIO TCMU backend and tcmu-runner provide for a configstring that is=20 associated with a given backstore. This is made available to the=20 handler, and sounds like just what qmp needs. > I made some patches to split this QMP machinery from the QEMU binary bu= t still > I don't know how a tcmu-runner plugin handler would be able to receive = this command > line configuration. The flow would be: 1) admin configures a LIO backstore of type "user", size 10G, and gives=20 it a configstring like "qmp/tcp:localhost,4444,server,nowait" 2) admin exports the backstore via whatever LIO-supported fabric(s)=20 (e.g. iSCSI) 3) tcmu-runner is notified of the new user backstore from step 1, finds=20 the handler associated with "qmp", calls=20 handler->open("tcp:localhost,4444,server,nowait") 4) qmp handler parses string and does whatever it needs to do 5) handler receives SCSI commands as they arrive > The second problem is that the QEMU block layer is big and filled with = scary stuff like > threads and coroutines but I think only trying to write the tcmu-runner= handler will > tell if it's doable. Yeah, could be tricky but would be pretty cool if it works. Let me know=20 how I can help, or with any questions. Regards -- Andy