This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-API] How Pygrub work on VHD

On Tue, 2010-01-26 at 03:11 -0800, Jonathan Ludlam wrote:
> On 25 Jan 2010, at 21:13, Dave Scott wrote:
> > 
> > Simply dd'ing an existing .vhd is risky because XCP is expecting
> > the .vhd to have a particular, optimized layout. In particular:
> > * extra space is left at the beginning of the file for later
> > resizing
> > * parent locators have a particular naming convention
> > * blocks are carefully aligned for performance
> > 
> > 
> And the VHD footer will be in the wrong place - this is more important
> than the other issues as I have observed tapdisk to get confused about
> the VHD, e.g. deciding that it's a dynamic disk rather than a
> differencing disk. You should wipe the footer (dd zero to the last
> sector in the LV), then the backup footer can be used to restore the
> footer into the correct place using "vhd-util modify -s <LV size> -n
> <path>"
> Our LVHD backends use vhd-util for all operations involving
> manipulation of VHDs - it will almost certainly be required in several
> ways for what you want to do. For example, it's probably OK to fix the
> 'extra space' issue mentioned above by using vhd-util to resize the
> VHD to the maximum possible size (~2Tb) and then back down to the
> original size. It can also be used to set the parent locators, so that
> might fix the naming convention issue. I suspect the block alignment
> might be a bit more tricky though - I can't think of a good way of
> fixing this. It might not be so important for you though.
> The best thing to do is probably to look through the python code of
> the LVHDSM backend to see exactly what it does, and how it uses
> vhd-util.
> Hope this helps!

Yes, this is really helpful, I'd like to visit the issue one by one.

1. VHD footer at wrong place,

I neglected this, my understanding is, for vhd file, vhd footer is at
the end of vhd file, when vhd file expand, it will copy vhd footer to
the new end first, then write other data blokc, for vhd volume, vhd
footer is at the end of this volume, if volume size is not changed, vhd
footer position doesn't change, this benefit performance. I assume
footer at the beginning of vhd file is exact same with that at the end
of vhd file. In this case, I can dd vhd file to a volume, then dd vhd
footer to last sector of this volume. does it works? or is there any
other difference about layout between vhd file and vhd volume?

2. Resize vhd,
resize vhd means resize virtual disk size, due to most OS doesn't
support it well, we'll not use it.

3. block/bitmap alignment,
I don't understand what's this!
normally block size is 2M, the bitmap for block is 4k (2M/512)? 
alignment may make sense for vhd file, but seem not mean anything for
volume, please enlighten me here!

4. extra space
how much is that?
the biggest size is 2T, I guest the biggest extra space is 2T/2M * 4=
4M, doesn't matter.

5. parent locator
I only use dd to copy template image between pool, so the vhd file
doesn't have parent.

If I'm wrong in someplace (I usually did that), please correct me, and
I'll take a closer look at LVHDSR code.

- Anthony


> Jon

xen-api mailing list

<Prev in Thread] Current Thread [Next in Thread>