Re: [Qemu-devel] [RFC PATCH] vpc: Ignore geometry for large images

[Jeff Cody]

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 <address@hidden> ---
> > >
> > >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?