From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [Qemu-devel] Re: KVM call minutes for June 8 Date: Fri, 11 Jun 2010 08:48:54 -0500 Message-ID: <4C123EC6.8080601@codemonkey.ws> 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> <4C10B3AF.5000201@redhat.com> <4C10E064.5090106@codemonkey.ws> <4C10E3B2.9070905@redhat.com> <4C10F656.20305@codemonkey.ws> <20100611095548.3d256bfb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kevin Wolf , "Daniel P. Berrange" , Chris Wright , kvm-devel , armbru@redhat.com, qemu-devel@nongnu.org To: Luiz Capitulino Return-path: Received: from mail-gy0-f174.google.com ([209.85.160.174]:53345 "EHLO mail-gy0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756298Ab0FKNtI (ORCPT ); Fri, 11 Jun 2010 09:49:08 -0400 Received: by gye5 with SMTP id 5so660424gye.19 for ; Fri, 11 Jun 2010 06:49:07 -0700 (PDT) In-Reply-To: <20100611095548.3d256bfb@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 06/11/2010 07:55 AM, Luiz Capitulino wrote: > On Thu, 10 Jun 2010 09:27:34 -0500 > Anthony Liguori wrote: > > >> On 06/10/2010 08:08 AM, Kevin Wolf wrote: >> >>> Am 10.06.2010 14:53, schrieb Anthony Liguori: >>> >>> >>>> On 06/10/2010 04:43 AM, Kevin Wolf wrote: >>>> >>>> >>>>> 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. >>>>> >>>>> >>>>> >>>> A live snapshot can last for a very long time. What happens if you need >>>> to allocate a new block for disk I/O while saving a snapshot? >>>> >>>> >>> You allocate it, I guess? >>> >>> Note that VM state must be virtually contiguous, but not necessarily >>> physically (virtually = on the virtual hard disk as seen by the guest; >>> physically = in the image file). It's just not seen by the guest because >>> it's saved at a high offset that is after the end of the real disk >>> content, but otherwise it should behave the same as guest data. >>> >>> >> I guess you could just start writing and then once your finished, you >> could update the snapshot information. So yeah, I think your right that >> it's doable with the current format. >> > No more issues on having them in QMP for 0.13 then? > I still think it's wrong to expose a broken command with no way for a user to detect whether it works or not. The fact that no other commands can run during it and the command may run for many minutes is still part of the protocol ABI IMHO. Regards, Anthony Liguori > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >