From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=50037 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OMeIO-0005xl-Ad for qemu-devel@nongnu.org; Thu, 10 Jun 2010 05:43:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OMeIN-0001xn-44 for qemu-devel@nongnu.org; Thu, 10 Jun 2010 05:43:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:22113) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OMeIM-0001xg-S4 for qemu-devel@nongnu.org; Thu, 10 Jun 2010 05:43:31 -0400 Message-ID: <4C10B3AF.5000201@redhat.com> Date: Thu, 10 Jun 2010 11:43:11 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: KVM call minutes for June 8 References: <20100608150500.GA28492@x200.localdomain> <4C0E694F.8040607@codemonkey.ws> <20100608175952.5f43ea8f@redhat.com> <4C0EB281.80907@codemonkey.ws> <20100609121820.1f3bb47a@redhat.com> <20100609153107.GE28326@redhat.com> <4C0FBFDF.5050009@codemonkey.ws> In-Reply-To: <4C0FBFDF.5050009@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Chris Wright , kvm-devel , qemu-devel@nongnu.org, armbru@redhat.com, Luiz Capitulino Am 09.06.2010 18:22, schrieb Anthony Liguori: > On 06/09/2010 10:31 AM, Daniel P. Berrange wrote: >>> However, libvirt was counting on this feature and on the snapshot commands >>> to switch from the text Monitor. We have two options: >>> >>> 1. Ask them to wait one more release (not so good for us) >>> 2. Try to find a way to have those features in for 0.13 >>> >>> Daniel has commented to me that making the snapshot commands synchronous >>> for 0.13 wouldn't be that bad, what do you think? >>> >> The thought is that changing a command from synchronous to asynchronous is >> not an ABI incompatible change. An existing app simply won't know to take >> advantage of the new possibilities that async commands offer. >> > > It's not QMP that's the major issue with savevm. The major issue is > actually the way snapshots are saved in qcow2. You need to know the > size of the snapshot prior to creating the snapshot Huh, why this? Seems I still haven't understood all of qcow2 then... I always thought that there's just a specific offset where VM state starts, but no explicit end. Kevin