qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH for 1.4] block/vpc: Fix size calculation


From: Jeff Cody
Subject: Re: [Qemu-devel] [PATCH for 1.4] block/vpc: Fix size calculation
Date: Mon, 11 Feb 2013 15:25:34 -0500
User-agent: Mutt/1.5.21 (2010-09-15)

On Mon, Feb 11, 2013 at 09:09:48PM +0100, Kevin Wolf wrote:
> Am 11.02.2013 20:38, schrieb Jeff Cody:
> > I've done some testing back and forth between VPC, Win Server 2012
> > Hyper-V, and qemu/kvm with and without this patch applied.
> 
> First of all, thanks a lot for doing all the testing!
> 
> > The short: this patch will break Virtual PC VHD compatibility (as it
> > exists under Win7), but allow compatibility for VHD files created by
> > Hyper-V (at least under Server 2012).
> > 
> > VPC and Server 2012 Hyper-V are also incompatible with each other,
> > when it comes to VHD files, if that is any consolation.
> 
> Okay. I had hoped that Win 7 would be fine as well and we might just get
> away with applying the patch, but this we can't possibly ignore.
> 
> > I used sha1sums between the different combination of VHD files filled to
> > capacity with random data under VPC, qemu/kvm (with & without the
> > patch), and Hyper-V.  Without this patch we are an exact math with
> > VPC, and with this patch we are an exact match with Hyper-V.
> > 
> > However, perhaps we can support both, depending on who created the VHD
> > file.  There is a "Creator Application" field in the VHD header - for
> > the VPC-created VHD file, that field is ASCII "vpc ".  For the Hyper-V
> > created VHD file, that field is ASCII "win ".  If we see the field as
> > "vpc ", we could default to using the CHS geometry found in the
> > header - otherwise, do as this patch does, and go by the virtual disk
> > size.
> 
> That they fill in different creator strings is good news. This isn't a
> nice solution, but then it wasn't nice to change the semantics between
> the two versions, so it's better than nothing. I'd vote for comparing
> the creator field.

+1 

> 
> One open question is what to do with images that are neither "vpc " (or
> "qemu") nor "win ". I think the newer behaviour is saner, but I don't
> know if there are other tools for which the old semantics should be used.
>

And it does get a bit trickier than that - it is possible to have a
creator field "lie".  Hyper-V does not give any warnings or errors
when opening the VPC VHD file, and since Hyper-V will just interpret
the disk as slightly larger, it will most likely work fine.  

But it is possible that Hyper-V will then modify the disk in a way
that uses the extra space (e.g. the guest reformatis / repartitions
the drive).  It does not update the creator field, so it still shows
the older "vpc ". If we went by that alone we would have the same
problem over again.

This is kind of a mess, but I think the best solution may be something
along the lines of:

1. By default, automatically use the creator field
2. Allow a way for the user to override this behavior, to allow manual
recovery from fringe cases

> The other question is what to do with newly created images. Maybe we
> should add a creation option. At the same time we should probably switch
> from the "qemu" creator string to something different if Hyper-V
> semantics is used, in order to allow distinguishing the version. I'm
> also not sure what the right default would be for now.
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]