From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49273) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPZSK-0002Hg-7V for qemu-devel@nongnu.org; Thu, 04 Sep 2014 12:00:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XPZSE-0001dl-2d for qemu-devel@nongnu.org; Thu, 04 Sep 2014 12:00:16 -0400 Received: from lputeaux-656-01-25-125.w80-12.abo.wanadoo.fr ([80.12.84.125]:47745 helo=paradis.irqsave.net) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XPZSD-0001dS-Ol for qemu-devel@nongnu.org; Thu, 04 Sep 2014 12:00:10 -0400 Date: Thu, 4 Sep 2014 17:59:21 +0200 From: =?iso-8859-1?Q?Beno=EEt?= Canet Message-ID: <20140904155921.GA12900@irqsave.net> References: <20140829172218.GD16755@irqsave.net> <20140902092510.GC29067@stefanha-thinkpad.redhat.com> <54065EE7.4080601@redhat.com> <20140903131159.GM28095@stefanha-thinkpad.redhat.com> <20140904132435.GA27852@irqsave.net> <5408821B.4070708@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <5408821B.4070708@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, Stefan Hajnoczi , pbonzini@redhat.com The Thursday 04 Sep 2014 =E0 08:15:39 (-0700), Andy Grover wrote : > On 09/04/2014 06:24 AM, Beno=EEt Canet wrote: > >>There are other commands for snapshots and backup which are issued vi= a > >>QMP. > >> > >>It might even make sense to make the tcmu interface available at > >>run-time in QEMU like the run-time NBD server. This allows you to ge= t > >>at read-only point-in-time snapshots while the guest is accessing the > >>disk. See the nbd-server-start command in qapi/block.json. > >> > >>Stefan > > > >Andy: ping > > > >I hope we didn't scaried you with our monster block backend and it's > >associated QMP socket ;) >=20 > Hi Beno=EEt, >=20 > No, I've gone off to work on a initial proof-of-concept implementation = of a > qemu-lio-tcmu.so module, hopefully it'll be ready to look at shortly an= d > then we can shoot arrows at it. :) Great !! >=20 > But in the meantime, do you have a use case or user story for the QMP > support that might help me understand better how it might all fit toget= her? >=20 Ok, 1) The cloud end user story --------------------------- My customer has implemented the AWS EC2 API to build his cloud. Simply said they are an AWS EC2 clone. The EC2 api provide a way for the end users (customers of my customer) to take snapshots of their VMs volumes programatically. Openstack surelly provide this too. The end users are taking snapshot every days since it's an easy way for them to have a point in time snapshot of their virtual machine. They can accumulate over 600 snapshots as the days pass. So the end users really needs snapshots. The EC2 compatible cloud only sane way to trigger a snapshotis to use a Q= MP socket. Right now my customer provide virtualized instances but the new use case = is to provide bare metal instances. tcmu could be used for this. I guess the openstack people will want to do the same at some point. The point is that the end users would still want to take snapshots of the= ir bare metal instances volumes. Not having this would break the EC2 API and make the i= nstances unusuable. 2) The cloud provider story --------------------------- End users make snapshot like crazy and eventually the QCOW2 backing chain= will make QEMU open more than FD_MAX files at once. QEMU will crash. Also the cloud provider has interest to shorten the backing chains (drop the oldest snapshots) in order to minimize the risk caused by a com= mon QCOW2 ancestor snapshot corruption. QEMU allows to do this with streaming. Streaming is triggered with a QMP = command. 3) The CEPH user story ---------------------- I know Red Hat is big on CEPH so: CEPH provide it's own kind of snapshotting. QEMU support it via QMP. 4) The any block operation you want to do with QEMU storage story ----------------------------------------------------------------- simple things such as collecting a block device statistic is also done vi= a QMP. And so on ... you can look in qapi/block-core.json to have an idea of QMP usefullness w= hile working with QEMU block devices. Best regards Beno=EEt > Regards -- Andy >=20 >=20