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

To: Dave Scott <Dave.Scott@xxxxxxxxxxxxx>
Subject: Re: [Xen-API] How Pygrub work on VHD
From: Jonathan Ludlam <Jonathan.Ludlam@xxxxxxxxxxxxx>
Date: Tue, 26 Jan 2010 11:11:52 +0000
Accept-language: en-US
Acceptlanguage: en-US
Cc: Anthony Xu <anthony@xxxxxxxxx>, "xen-api@xxxxxxxxxxxxxxxxxxx" <xen-api@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 26 Jan 2010 03:12:25 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <81A73678E76EA642801C8F2E4823AD2143E92238EE@xxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-api-request@lists.xensource.com?subject=help>
List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
List-post: <mailto:xen-api@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-api>, <mailto:xen-api-request@lists.xensource.com?subject=unsubscribe>
References: <1264451889.2927.3.camel@mobl-ant> <81A73678E76EA642801C8F2E4823AD2143E92238EB@xxxxxxxxxxxxxxxxxxxxxxxxx> <1264452764.2927.14.camel@mobl-ant> <81A73678E76EA642801C8F2E4823AD2143E92238EE@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcqeeF0iCqMtzG+gRaKCFWr1ZbjFDw==
Thread-topic: [Xen-API] How Pygrub work on VHD

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!


xen-api mailing list