Glad the blog post is of use. It’s a while since I wrote it so I had to re-read
it myself. I have not come across this problem – but as you can probably guess
we luckily don’t have to do this recovery procedure very often.
I can only assume same as yourself that the vhd-util coalesce using the
downloaded vhd-util binary must give a slightly different format header which
the import in CloudStack doesn’t like but XS is quite happy about. Also keep in
mind that the vhd-util from
http://download.cloud.com.s3.amazonaws.com/tools/vhd-util is slightly different
than the one you find on the XenServers, so this may also be a factor.
Please let us know how you get on with your investigation – if you find the
root cause let me know and I’ll add it as a subnote to the original article
(don’t worry you’ll get the credit ( ).
On 22/02/2018, 00:10, "Grégoire Lamodière" <g.lamodi...@dimsi.fr> wrote:
I recently lost a Xen 7 pool managed by CS 4.11 (hardware issue).
I tried to apply Dag's excellent article
found a strange behavior :
- If I directly export the VHD from old NFS primary storage (after
coalesce vhd with vhd-util) and import to CS using import Template, they always
fail, with 2 types of error (mainly Failed post download script: vhd remove
- If I use the same VHD, import-it to a xen server (xe
vdi-import), and then export it (xe vdi-export), I can successfully import it
I made tries with Windows instances, from 15 to 100 Gb, and always the same
And I also made the same to a CS 4.7 with same results.
A quick look inside createtmplt.sh did not show anything relevant.
I guess the header / footer might have some differences, I'll check this
Is anyone aware of this ?
Is there any solution to avoid the intermediate vdi-import / export.
I will dig a bit more to find a proper solution, as it sounds interesting
to get a disaster migration script working fine.
T/ + 33 6 76 27 03 31
F/ + 33 1 75 43 89 71
53 Chandos Place, Covent Garden, London WC2N 4HSUK