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!
Jon
| 
