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

Anthony Xu wrote:
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
* 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
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

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?
I believe this should work, however simply removing the footer and allowing the VHD tools to repair the file is probably the safest and easiest method.
2. Resize vhd,
resize vhd means resize virtual disk size, due to most OS doesn't
support it well, we'll not use it.
Agreed, you still have to resize the filesystem that resides on top of the virtual disk, although for linux there are tools that allow you to do this dynamically.
3. block/bitmap alignment,
I don't understand what's this!
normally block size is 2M, the bitmap for block is 4k (2M/512)?
The VHD block size is 2M, however the VHD spec does not require that either the initial data offset following the VHD header and parent locator fields is 4k aligned, nor does it specify that the first sector following a block bitmap on disk must be 4k aligned. When creating a new VHD file via the VHD tools in XCP, it ensures that all these components are aligned such that disk aligned IO requests from the guest are also aligned with the physical storage.
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.
The key point here is that resizing a VHD where the initial data offset already provides sufficient space for the BAT table to grow does not require an atomic stop and pause of the active device handlers. If the initial data offset is not provisioned to accomdate a larger disk virtual size when the disk is created, a resize involves relocating data blocks to the end of the VHD file which must be done atomically with no other processes reading the VHD at the same time.

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


xen-api mailing list

xen-api mailing list

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