|
xen-api
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
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?
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.
Thanks,
Julian
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.
Thanks,
- Anthony
Jon
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api
|
|
|
Home