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 ( ). Regards, Dag Sonstebo Cloud Architect ShapeBlue 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 /mnt/SecStorage/2da072e7-a6fe-3e39-b07e-77ec4f34fd49/template/tmpl/2/258/dnld5954086457185109807tmp_ 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 result. 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 tomorrow. 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. Regards. --- Grégoire Lamodière T/ + 33 6 76 27 03 31 F/ + 33 1 75 43 89 71 dag.sonst...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue
