Thanks for the update Gregoire,
Would you be able to check the vhd-util versions in your working vs not-working
scenarios?
Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue
On 06/03/2018, 22:11, "Grégoire Lamodière" <g.lamodi...@dimsi.fr> wrote:
Hi Dag, All,
I spent some time working on this matter, and here are the results of my
tests.
It might be usefull in case anyone has to restore instances from nfs store.
I think I were facing 2 issues.
1/ You are right, in case vm crashed (ie was running at the time of network
crash), you may assume around 50% luck to restore it easily.
2/ vhd-util version used in the xenserver seems to be the key of the
process.
I made the following tries :
- take vhd from cs 4.9.3 / xenserver 7.0
- download VHD-UTIL from install guide url
- Import it to cs 4.11 / xenserver 7.0 => not working
- Upgrade the xenserver to 7.2 => import still not working
- Import directly to xenserver 7.0 / 7.2 => working 100%
- make exactly the same, copying vhd-util from original cs 4.9.3 management
server to the new one
- Import it to cs 4.11 / xenserver 7.0 => working
- Upgrade the xenserver to 7.2 => import working
So from what I can see :
Vdi-import always works in a Xenserver perspective, but in some cases vm
won't start properly if they were inconsistent.
When vhd is downloaded as a template in cs, the errors reported were mostly
post-download errors, ex. In the ssvm script :
vhd-util set -n ${tmpltimg2} -f "hidden" -v "0" > /dev/null
rollback_if_needed $tmpltfs $? "vhd remove $tmpltimg2 hidden failed\n
That’s all for my feedback.
In case anyone needs info or scripts, I'll be happy to share.
Now it's time to continue my work moving to KVM, but that is another story.
Regards
Grégoire
---
Grégoire Lamodière
T/ + 33 6 76 27 03 31
F/ + 33 1 75 43 89 71
-----Message d'origine-----
De : Grégoire Lamodière [mailto:g.lamodi...@dimsi.fr]
Envoyé : vendredi 23 février 2018 21:10
À : users@cloudstack.apache.org
Objet : RE: VHD import
Hi Dag,
I am still trying to understand, but some instances crashed where some
others shutdown properly.
So far, I can confirm that all vhd (after coalesce) can be imported to Xen,
and most of them fail to import as VHD.
Some failure imports are successful after the Xen import step, but some
still fail after the xe vhd-export (xen vm is working fine)
The strange thing is all vhd sound good (all steps of the cs script pass,
but the process results in cs errors).
This is not a big deal, as we are moving to KVM, but I hope we won't have
the same issues with kvm nfs based volumes.
I'll work on this a bit this weekend, so I can make a proper feedback.
Anyway, once again, thanks for your blog post, clear and usefull, as usual.
Grégoire
---
Grégoire Lamodière
T/ + 33 6 76 27 03 31
F/ + 33 1 75 43 89 71
-----Message d'origine-----
De : Dag Sonstebo [mailto:dag.sonst...@shapeblue.com]
Envoyé : vendredi 23 février 2018 20:48
À : users@cloudstack.apache.org
Objet : Re: VHD import
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
dag.sonst...@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
