From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44172) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLB5c-0003Et-8p for qemu-devel@nongnu.org; Tue, 10 Feb 2015 08:43:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YLB5X-0002Uc-Jd for qemu-devel@nongnu.org; Tue, 10 Feb 2015 08:42:56 -0500 Received: from mx1.redhat.com ([209.132.183.28]:33795) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YLB5X-0002UV-C3 for qemu-devel@nongnu.org; Tue, 10 Feb 2015 08:42:51 -0500 Date: Tue, 10 Feb 2015 08:42:42 -0500 From: Jeff Cody Message-ID: <20150210134242.GB19775@localhost.localdomain> References: <1423498163-2001-1-git-send-email-kwolf@redhat.com> <54D9EE7A.9050802@kamp.de> <20150210133414.GE5202@noname.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150210133414.GE5202@noname.str.redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH] vpc: Ignore geometry for large images List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Peter Lieven , qemu-devel@nongnu.org, stefanha@redhat.com On Tue, Feb 10, 2015 at 02:34:14PM +0100, Kevin Wolf wrote: > Am 10.02.2015 um 12:41 hat Peter Lieven geschrieben: > > Am 09.02.2015 um 17:09 schrieb Kevin Wolf: > > >The CHS calculation as done per the VHD spec imposes a maximum > > >image size of ~127 GB. Real VHD images exist that are larger than > > >that. > > > > > >Apparently there are two separate non-standard ways to achieve > > >this: You could use more heads than the spec does - this is the > > >option that qemu-img create chooses. > > > > > >However, other images exist where the geometry is set to the > > >maximum (65536/16/255), but the actual image size is larger. > > >Until now, such images are truncated at 127 GB when opening them > > >with qemu. > > > > > >This patch changes the vpc driver to ignore geometry in this case > > >and only trust the size field in the header. > > > > > >Signed-off-by: Kevin Wolf --- > > > > > >Peter, I'm replacing some of your code in the hope that the new > > >approach is more generally valid. Of course, I haven't tested if > > >your case with disk2vhd is still covered. Could you check this, > > >please? > > > > I checked this and found that disk2vhd always sets CHS to 65535ULL > > * 16 * 255 independed of the real size. > > > > But, as the conversion to CHS may have an error its maybe the best > > solution to ignore CHS completely and always derive total_sectors > > from footer->size unconditionally. > > > > I had a look at what virtualbox does and they only rely on > > footer->size. If they alter the size or create an image the write > > the new size into the footer and recalculate CHS by the formula > > found in the appendix of the original spec. > > > > Check vhdCreateImage, vhdOpen in > > http://www.virtualbox.org/svn/vbox/trunk/src/VBox/Storage/VHD.cpp > > > > The original spec also says that CHS values purpose is the use in > > an ATA controller only. > > The problem with just using footer->size back then when I > implemented this was that from the perspective of a VirtualPC guest > run in qemu, the size of its hard disk would change, which you don't > want either. Going from VPC to qemu would be ugly, but mostly > harmless as the disk only grows. But if you use an image in qemu > where the disk looks larger and then go back to VPC which respects > geometry, your data may be truncated. > I believe the vpc "creator" field is different if the image was created by Virtual PC, versus created by Hyper-V ("vpc" and "win", respectively, I think). Perhaps we could use that to infer a guest image came from VirtualPC, and thus not use footer->size in that scenario?