Hi Gregoire,

One thing just struck me – what was the status of the VMs you were exporting 
from NFS? Were they cleanly shut down or did they simply crash when the 
hardware failed? If so could you have an issue where the disk you are initially 
exporting isn’t consistent, hence import fails? 

Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue

On 22/02/2018, 09:56, "Dag Sonstebo" <dag.sonst...@shapeblue.com> wrote:

    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
      
     
    
    


dag.sonst...@shapeblue.com 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Reply via email to