From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36228) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XNl6b-00077B-O2 for qemu-devel@nongnu.org; Sat, 30 Aug 2014 12:02:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XNl6X-0007Su-2D for qemu-devel@nongnu.org; Sat, 30 Aug 2014 12:02:21 -0400 Received: from mx1.redhat.com ([209.132.183.28]:65184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XNl6W-0007So-OW for qemu-devel@nongnu.org; Sat, 30 Aug 2014 12:02:16 -0400 Date: Sat, 30 Aug 2014 17:02:12 +0100 From: "Richard W.M. Jones" Message-ID: <20140830160212.GH1302@redhat.com> References: <20140829172218.GD16755@irqsave.net> <20140830144641.GM14001@redhat.com> <20140830155343.GA2212@irqsave.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20140830155343.GA2212@irqsave.net> 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, agrover@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com On Sat, Aug 30, 2014 at 05:53:43PM +0200, Beno=EEt Canet wrote: > The Saturday 30 Aug 2014 =E0 15:46:41 (+0100), Richard W.M. Jones wrote= : > > For the benefit of those who have absolutely no idea what you're > > talking about, could you write a simpler summary of what you're tryin= g > > to do? > >=20 > > Rich. >=20 > Hello, >=20 > Most cloud providers sell virtualized instances either using Xen or KVM. > > However another trend is to provide bare metal instances for people > who want the highest CPU and network performance possible.(typicaly > people doing computation with MPI) > > So a cloud end user would need to be able to instanciate a virtual > machine use it for a while then stop the virtual machine, change the > hardware type to bare metal and restart the instance while keeping > using the same boot volume. > > QEMU will keep a virtual machine data stored in one of it's numerous > storage backend format like QCOW2 or QED. > > 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). I think this is an excellent idea, although AIUI iSCSI is a pretty complex protocol. (I wrote an NBD server, and the protocol is almost trivial, albeit as you say, performing badly). > So summarize I am looking for a way to export QCOW2 or QED image as > an ISCSI or FCOE targets while keeping all the goodies these format > provides (taking snapshots for backup, streaming, mirroring). > > Reusing LIO code would help tremendously to simplify this task. I guess so. Are you planning to integrate bits of LIO into qemu, or bits of qemu into LIO? 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. Writing an iSCSI front end to qemu would be good, but qemu has some very particular policies about what code can be introduced, so that could be tricky too ... Rich. --=20 Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rj= ones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org