Hi Gregoire,

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 ( ).

Dag Sonstebo
Cloud Architect

On 22/02/2018, 00:10, "Grégoire Lamodière" <g.lamodi...@dimsi.fr> wrote:

    Dear All,
    I recently lost a Xen 7 pool managed by CS 4.11 (hardware issue).
    I tried to apply Dag's excellent article 
(http://www.shapeblue.com/recovery-of-vms-to-new-cloudstack-instance/), and 
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 
 hidden failed).
    -          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 
to CS
    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.
    Grégoire Lamodière
    T/ + 33 6 76 27 03 31
    F/ + 33 1 75 43 89 71

53 Chandos Place, Covent Garden, London  WC2N 4HSUK

Reply via email to