On 16.11.2015 21:58, Max Reitz wrote: > On 13.11.2015 16:32, Lucian Petrut wrote: >> >> 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 <lpet...@cloudbasesolutions.com> >> --- >> Proposed fix for https://bugs.launchpad.net/qemu/+bug/1490611 >> >> block/vpc.c | 32 ++++++++------------------------ >> 1 file changed, 8 insertions(+), 24 deletions(-) >> > > CC-ing Peter. > > Looks right, considering page 7 of the spec: > > (http://download.microsoft.com/download/f/f/e/ffef50a5-07dd-4cf8-aaa3-442c0673a029/Virtual%20Hard%20Disk%20Format%20Spec_10_18_06.doc) > > "When the user creates a hard disk of a certain size, the size of the > hard disk image in the virtual machine is smaller than that created by > the user. This is because CHS value calculated from the hard disk size > is rounded down." > > However, this patch looks incomplete, note the comment you are removing: > "This ensures that qemu-img convert doesn't truncate images". This is > because vpc_open() prefers the CHS size over the current_size value, and > as far as I remember there was indeed a good reason for that (some > application had invalid values for current_size, or something like that). > > So at the very least, we will have to change vpc_open() to always use > the value from footer->current_size and ignore > footer->{cyls,heads,secs_per_cyl}, otherwise qemu will always consider > these images smaller than they actually are (which is bad, at least when > converting images). > > But I'd like to know from Peter whether he remembers the reason why > vpc_open() tries to ignore footer->current_size in the first place...
OK, so it was just qemu-devel having hiccups again. Now the mails are rolling in... > Max > > > PS: If possible, the "From: " header in an emailed patch should match > the Signed-off-by line. I think. It doesn't state that in > http://wiki.qemu.org/Contribute/SubmitAPatch, but the commit looks > strange otherwise. So I guess if it isn't reasonably possible, it's not > too bad. :-) >
signature.asc
Description: OpenPGP digital signature
