From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36902) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyJCe-0005ly-Cv for qemu-devel@nongnu.org; Mon, 16 Nov 2015 07:48:13 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZyJCZ-0005cc-On for qemu-devel@nongnu.org; Mon, 16 Nov 2015 07:48:12 -0500 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:60864 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZyJCZ-0005c0-GA for qemu-devel@nongnu.org; Mon, 16 Nov 2015 07:48:07 -0500 References: <1447428724-28116-1-git-send-email-lpetrut@cloudbasesolutions.com> <20151116091711.GA4182@noname.str.redhat.com> <20151116122257.GA847@localhost.localdomain> From: Peter Lieven Message-ID: <5649D081.6090200@kamp.de> Date: Mon, 16 Nov 2015 13:48:01 +0100 MIME-Version: 1.0 In-Reply-To: <20151116122257.GA847@localhost.localdomain> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] block/vpc: Fix vhd extra sectors issue List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jeff Cody , Kevin Wolf Cc: Lucian Petrut , Lucian Petrut , qemu-devel@nongnu.org Am 16.11.2015 um 13:22 schrieb Jeff Cody: > On Mon, Nov 16, 2015 at 10:17:11AM +0100, Kevin Wolf wrote: >> Am 13.11.2015 um 16:32 hat Lucian Petrut geschrieben: >>> At the moment, qemu-img extends new image virtual sizes based >>> on the CHS algorithm provided by the VHD specs in order to >>> ensure that the disk geometry (and payload as seen by some >>> guests which use the CHS value) can fit in the requested disk. >>> >>> This patch drops this behavior, as it breaks compatibility with >>> Azure, which requires the MB alignment to be preserved. >>> >>> Signed-off-by: Lucian Petrut >>> --- >>> Proposed fix for https://bugs.launchpad.net/qemu/+bug/1490611 >> This may fix one scenario, but it's sure to break others which are >> currently working. The problem has been discussed more than once and >> it's essentially a problem with MS using their own file format >> inconsistently. >> >> I think we once came to the conclusion that looking at the creator >> string might be a working heuristics. Apparently this was never >> implemented - I don't remember whether that was because we noticed a >> problem with it, or just because noone got to it. >> >> Jeff and Peter, I seem to remember that you were involved the last time >> we discussed this, so does one of you remember why we didn't implement >> this heuristics in the end? >> > I believe we can look at the creator field. The VHD files created by > Virtual PC and Hyper-V differed, but we could theoretically > differentiate between by the creator field. > > I'm not sure if there was anything that actually blocked the > implementation. It may have just been because we weren't sure if this > was the case across all versions of VPC and Hyper-V, although I > suspect it is (as an aside - is VirtualPC essentially dead, or is it > maintained / supported by MS?). If I remember correctly we were looking at the creator field for disk2vhd images and used the size from the footer in this case. Later we changed that to use the size from the footer if CHS is 65535x255x255. disk2vhd always sets this geometry regardless of the size. The issue is whatever we do if we interpret the disk size larger than expected by some other application. If I remember correctly VirtualBox uses the size from the footer anytime we do not mount the container as an IDE device. Peter