[Edit]MAJ le 19/10 avec quelques captures d’écran[/Edit]
Une manière simple de créer et de déployer des templates sous ESXi lorsqu’on ne dispose pas du vCenter et de la licence qui va bien est d’utiliser les templates OVF/OVA (cf un de mes tous premiers articles). Je l’utilise d’ailleurs toujours aujourd’hui pour pallier le manque de licences sur certains sites distants/secondaires.
Cependant, depuis la version 5 (ou peut être 5.1), j’ai été confronté à plusieurs reprises à l’erreur suivante lors du déploiement de l’OVA :
Echec déploiement package OVF: Cette tâche a été annulée par un utilisateur
WTF ? Pas de code d’erreur, et un message pas vraiment loquasse…
J’ai eu beaucoup de mal à trouver la réponse à cette erreur en Français et il a d’ailleurs fallu que je le traduise mot pour mot en anglais pour trouver des ressources pour m’aider :
Failed to deploy OVF package: The task was canceled by a user.
[Edit] En 5.5, j’ai également rencontré le message suivant qui donne un peu plus d’informations sur le problème réel :
OVF Deployment Failed: File ds:///vmfs/volumes/uuid/_deviceImage-0.iso was not found
[/Edit]
Et là on commence à trouver un peu d’aide sur le web. Parmi les liens intéressants sur le sujet, on peut citer le KB de VMware et lukebarklimore qui rentre un peu dans le détail de l’anatomie d’un OVF/OVA de chez VMware :
- http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2034422
- https://lukebarklimore.wordpress.com/2012/10/25/esxi-5-1-fixing-failed-to-deploy-ovf-package-the-task-was-canceled-by-a-user/
Ce qu’il faut en retenir, c’est :
- un OVA n’est en fait qu’une simple archive tar (qu’on peut donc ouvrir avec un « tar xf » ou un 7zip pour les Windowsiens
- Il contient un fichier .ovf au format XML qui respecte la norme des OVF (enfin, si on peut appeler ça une norme ! troll) et qui est en fait un descripteur du matériel virtuel de votre VM
- un ou plusieurs fichiers .vmdk, vos disques durs virtuels
- un fichier .mf qui ne contient en fait que le hash sha1 du fichier, pour le contrôle de la cohérence
Pour en venir au problème en lui même : il se produit lorsque les VMware Tools sont mal démontés ou se sont mal installés (ou mal terminé d’installer). La machine virtuelle garde en mémoire la présence de l’ISO et celui ci reste inscrit dans le descripteur OVF. Lorsqu’on déploie la VM, l’ISO n’est plus présent sur le serveur de destination et on obtient l’erreur susnommée.
Pour résoudre le problème, il faut donc :
- Extraire le fichier OVF de l’archive OVA
- Editer le fichier OVF, et remplacer la mention vmware.cdrom.iso par la valeur vmware.cdrom.atapi ou vmware.cdrom.remotepassthrough
- Recalculer le nouveau hash SHA1 du fichier OVF édité
- Recréer une archive et y ajouter DANS CET ORDRE les fichiers .ovf PUIS .mf et .vmdk.
tar xf maVM.ova #extraction des fichiers de l'archive
rm maVM.ova
vi maVM.ovf #si vous êtes sages je vous donnerai un "sed" pour éviter d'avoir à éditer le fichier
sha1sum maVM.ovf #récupérer le retour et remplacer le hash de l'OVF par la nouvelle valeur dans le fichier maVM.mf
tar cf maVM.ova maVM.ovf #recréation de l'archive
tar uf maVM.ova *.mf *.vmdk
Si vous omettez de recalculer le checksum, VMware vous expliquera bien gentiment que le checksum n’est pas bon, et donc l’archive toute entière, donc pas de flemme !
Et si vous ne les mettez pas dans cet ordre, vous aurez une autre erreur, très explicite cette fois ci qui vous expliquera que votre OVA est invalide car les fichiers ne sont pas dans le bon ordre… Oui… Vraiment.