From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48354) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bmKQv-0007da-8R for qemu-devel@nongnu.org; Tue, 20 Sep 2016 08:45:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bmKQr-0000qc-4G for qemu-devel@nongnu.org; Tue, 20 Sep 2016 08:45:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:54634) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bmKQq-0000qF-UQ for qemu-devel@nongnu.org; Tue, 20 Sep 2016 08:45:53 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8FCE4C05A28E for ; Tue, 20 Sep 2016 12:45:51 +0000 (UTC) Date: Tue, 20 Sep 2016 13:45:49 +0100 From: "Richard W.M. Jones" Message-ID: <20160920124549.GA27578@redhat.com> References: <20160920114103.27aeea2a@fiorina> <20160920133529.05889b97@fiorina> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160920133529.05889b97@fiorina> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 2/2] qemu-nbd: Add --image-size option List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?utf-8?B?VG9tw6HFoSBHb2xlbWJpb3Zza8O9?= Cc: Paolo Bonzini , qemu-devel@nongnu.org On Tue, Sep 20, 2016 at 01:35:29PM +0200, Tom=C3=A1=C5=A1 Golembiovsk=C3=BD= wrote: > The second patch tries to solve the situation when you have file: >=20 > || some data ; image ; some more data || >=20 > In this case there is no way to say where the image ends and client may > also access content in the "some more data" area. Thus corrupting the > data outside the image. Some background: A use case for this is to be able to access a disk image which is located inside an OVA file, without unpacking the OVA. An OVA file is [usually, not always] an uncompressed tar file. It is relatively easy to find the offset and size of the contained disk image, since tar files are essentially concatenations of header + data + header + ... OVA files may be terabytes in size, so avoiding unpacking is desirable since it can save masses of disk space and time. One place we could use this feature would be in virt-v2v. Rich. --=20 Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rj= ones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html