From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37788) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBjZz-0007dd-2U for qemu-devel@nongnu.org; Tue, 20 Aug 2013 06:54:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VBjZq-0003hA-LO for qemu-devel@nongnu.org; Tue, 20 Aug 2013 06:54:26 -0400 Received: from mail-wi0-x22c.google.com ([2a00:1450:400c:c05::22c]:35868) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VBjZq-0003h5-FD for qemu-devel@nongnu.org; Tue, 20 Aug 2013 06:54:18 -0400 Received: by mail-wi0-f172.google.com with SMTP id hj13so4164674wib.11 for ; Tue, 20 Aug 2013 03:54:17 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <52134AAF.6050802@redhat.com> Date: Tue, 20 Aug 2013 12:53:35 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <4A946BEF1E0D5A89DFF0499F@Ximines.local> <20130819112335.GA27849@localhost.localdomain> <1960DADA-9E1D-48EF-9AE4-2805F0787E70@alex.org.uk> <20130820014243.GA7602@localhost.localdomain> <90D0FA8B-A032-4608-9CAA-B5BC26DC4D75@alex.org.uk> <20130820070859.GA11944@localhost.localdomain> In-Reply-To: <20130820070859.GA11944@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] vmdk stream-optimised format List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: famz@redhat.com Cc: qemu-devel@nongnu.org, Alex Bligh Il 20/08/2013 09:08, Fam Zheng ha scritto: > On Tue, 08/20 07:51, Alex Bligh wrote: >> >> On 20 Aug 2013, at 02:42, Fam Zheng wrote: >> >>> OK, thanks for explaination. That sounds a valid use case for >>> streamOptimized. However I am afraid QEMU and its users benefit not much >>> from this feature anyway, because it's moving a VM away to VMware, :) >>> that might be the reason it's not there yet, and I don't know about any >>> plan to do it in the near future. >> >> Well, given it is an open source project, the more interoperability >> the better. Even if it just means users need not worry about lock >> in to faster hypervisors ... Being more serious, qemu-img is >> part of the project too. >> >>> But if someone sends patches for this, I think it is possible to get in. >> >> I guessed "send code" might be the answer :-) >> >> What I'm not sure of is whether the streaming format has to be written >> sequentially from as opposed to random writes. I believe the way >> qemu-img convert works, one can't guarantee the writes are >> sequential. >> > The order of sectors doesn't matter, but granularity should be aligned > to, as the data is compressed cluster by cluster. And no overwrite, of > course. The challenge may be that header comes at the end of file > (well, called footer), which is not decided at create time. It doesn't look too different from what "qemu-img convert -c" does, except that you need to use the right "-o" incantation to specify the format type. Paolo