From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56054 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ou772-0005sO-O3 for qemu-devel@nongnu.org; Fri, 10 Sep 2010 13:10:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Ou771-0002dV-8y for qemu-devel@nongnu.org; Fri, 10 Sep 2010 13:10:08 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:57929) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ou771-0002dN-3N for qemu-devel@nongnu.org; Fri, 10 Sep 2010 13:10:07 -0400 Received: by gxk22 with SMTP id 22so862825gxk.4 for ; Fri, 10 Sep 2010 10:10:06 -0700 (PDT) Message-ID: <4C8A666A.3080608@codemonkey.ws> Date: Fri, 10 Sep 2010 12:10:02 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format References: <4C86BC6B.5010809@codemonkey.ws> <4C874812.9090807@redhat.com> <4C87860A.3060904@codemonkey.ws> <4C888287.8020209@redhat.com> <4C88D7CC.5000806@codemonkey.ws> <4C8A1311.8070903@redhat.com> <4C8A15C4.40201@redhat.com> <4C8A19CA.3040000@redhat.com> <4C8A3106.8050501@codemonkey.ws> <20100910134859.GB28831@lst.de> <4C8A488B.2090907@codemonkey.ws> <4C8A4C61.2030905@redhat.com> <4C8A5488.9000409@codemonkey.ws> <4C8A575E.7080505@redhat.com> In-Reply-To: <4C8A575E.7080505@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: qemu-devel@nongnu.org, Stefan Hajnoczi , Christoph Hellwig , Stefan Hajnoczi , Avi Kivity On 09/10/2010 11:05 AM, Kevin Wolf wrote: > Am 10.09.2010 17:53, schrieb Anthony Liguori: > >> On 09/10/2010 10:18 AM, Kevin Wolf wrote: >> >>> Am 10.09.2010 17:02, schrieb Anthony Liguori: >>> >>> >>>> What makes us future proof is having a good feature support. qcow2 >>>> doesn't have this. We have a good way at making purely informational >>>> changes and also making changes that break the format. Those features >>>> are independent so they can be backported in a compatible way too. >>>> >>>> >>> I might have agreed that it's useful to be able to backport them >>> independently if we had had lots of such features added in the past. But >>> we haven't. >>> >>> >> I think part of why we haven't had them is that the mechanisms aren't >> very flexible. >> >> A good example of where feature support would be very nice is for >> changing the way snapshots metadata is recorded in qcow2. >> >> It would be nice to be able to represent snapshots with a uuid. If you >> added new metadata that had uuid based snapshots that were hierarchical >> and added a feature bit, it would have some nice properties. >> >> Since most images don't have snapshots, the common case would be a qcow2 >> that was fully backwards compatible. You would also get a graceful >> failure for using a new image with an old QEMU. >> > Well, snapshots have an ID today (which is different from their name). > Nobody stops you from putting a UUID there. Fully backwards compatible, > no feature flag needed. I think Miguel was planning to actually do this. > The problem is that management tools have to make a decision about what to do with ID's that aren't UUIDs which means that in our management interface, we can't just expose UUIDs but instead we have to expose strings that may sometimes be UUIDs. I don't think it buys us a lot to get the backwards compatibility. Regards, Anthony Liguori > Kevin >