From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33929) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XNPtH-0006oc-U1 for qemu-devel@nongnu.org; Fri, 29 Aug 2014 13:23:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XNPtC-0003FY-MY for qemu-devel@nongnu.org; Fri, 29 Aug 2014 13:23:11 -0400 Received: from lputeaux-656-01-25-125.w80-12.abo.wanadoo.fr ([80.12.84.125]:44754 helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XNPtC-0003FQ-G3 for qemu-devel@nongnu.org; Fri, 29 Aug 2014 13:23:06 -0400 Date: Fri, 29 Aug 2014 19:22:18 +0200 From: =?iso-8859-1?Q?Beno=EEt?= Canet Message-ID: <20140829172218.GD16755@irqsave.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] tcmu-runner and QEMU List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: kwolf@redhat.com, pbonzini@redhat.com, agrover@redhat.com, stefanha@redhat.com Hi list, Listening at Palo's suggestion I started discussing privately with Andy about integrating LIO and the QEMU block layer together using tcmu-runner: https://github.com/agrover/tcmu-runner. The rationale is that it would be very handy to be able to export one of = the numerous QEMU image formats into ISCSI or FCOE via the LIO kernel target. For example a cloud provider would be able to provision either a bare met= al instance (some hardware knows how to boot ISCSI and FCOE) or a virtualized instanc= e while using the same QCOW2 backing chain. The consequence is that the end user would be able to switch back and for= th between small virtualized hardware or monster bare metal hardware while keeping t= he same data in the same volumes. Quoting Andy: "My initial thought is that we don't want to make tcmu-runner QEMU-specific, what we really want is tcmu-runner to be able to use QEMU's multitude of BlockDrivers. Ideally the BlockDrivers could be compiled as loadable modules that could then be loaded by QEMU or tcmu-runner. Or if that's not possible then we might need to build a tcmu-runner handler as part of QEMU, similar to how qemu-nbd is built?" The truth is that QEMU block drivers don't know how to do much on their o= wn so we probably must bring the whole QEMU block layer in a tcmu-runner ha= ndler plugin. Another reason to do this is that the QEMU block layer brings features li= ke taking snapshots or streaming snaphots that a cloud provider would want to keep = 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 argument = then connecting on this JSON processing socket then send orders to QEMU. I made some patches to split this QMP machinery from the QEMU binary but = still I don't know how a tcmu-runner plugin handler would be able to receive th= is command line configuration. Some other configuration would be needed to configurate properly the QEMU= block layer: for example which cache mode should the handler use ? So passing configuration to the QEMU block plugin would be the first crit= ical point. The second problem is that the QEMU block layer is big and filled with sc= ary stuff like threads and coroutines but I think only trying to write the tcmu-runner h= andler will tell if it's doable. Best regards Beno=EEt