Déploiement on Zwindler's Reflection

Pourquoi Helm 2 doit disparaître

Mon, 19 Apr 2021 07:59:14 +0000

Deployer sur Kubernetes avec Helm, c’est vraiment se faire du mal

Je ne sais plus qui parmi vous écrivait il y a peu « Avec Kubernetes, c’est un peu une love/hate relationship ». J’adore Kubernetes, particulièrement dans les contextes où il résout des « million-dollar problems ». Mais alors… QU’EST CE QUE JE DETESTE HELM.

Je rage / shitpost régulièrement sur Helm, mais malheureusement il n’y a pas tant d’alternatives pour déployer facilement dans Kubernetes (oui je sais qu’il y en a, ce n’est pas le but du post).

Mais attend, tu parles de Helm 2 dans ton titre ?

Ça fait des années que j’ai ce brouillon en attente sur le blog (encore un, me direz-vous). Je commençais à me dire que ce n’avait plus vraiment d’intérêt de le poster maintenant que Helm 2 est officiellement déprécié et remplacé par Helm 3 depuis quasiment 1 an.

Mais j’ai lu un chouette article de serveur410 il y a quelques jours qui m’a décomplexé de poster des articles anachroniques (et je vous invite à aller lire cet article, que vous ayez un blog ou non).

Donc oui, je vais parler d’une techno dépréciée depuis plus d’un an et dont le remplaçant qui est censé magiquement régler tous les problèmes est apparu en 2019.

Pour autant, ce n’est pas parce que cet article va parler de Helm 2, de ses bugs que j’ai rencontrés et de comment on se sort de chaque situation pourrie. Le plus simple étant de passer à Helm 3, même sil est pété lui aussi (on en reparlera sûrement).

Déployer avec Helm2, quel enfer !

Mais revenons à Helm 2. En 2018/2019, je déploie en production des applications dans un Kubernetes managé qu’on manage nous-même (trop long à expliquer ;-p).

On avait la « flemme » de migrer de Helm 2 à Helm 3 et franchement on a vraiment eu tort. Je vais vous faire une petite histoire vraie de ce qui s’est passé lorsque j’ai essayé de redéployer un prometheus.

La genèse

Pour une raison qui m’échappe (car le brouillon est beaucoup trop vieux), j’ai commencé par supprimer la release helm plutôt que d’upgrade mon déploiement (la release devait être dans un état foireux, et comme Helm 2 ne supporte pas le 3-way merge…).

Je supprime donc ma release.

zwindler$ helm delete prometheus
release "prometheus" deleted

Je ne peux donc plus « upgrade » ma release puisqu’elle n’existe plus.

zwindler$ helm upgrade prometheus stable/prometheus
Error: UPGRADE FAILED: "prometheus" has no deployed releases

So far, so good

J’essaye donc de la réinstaller

zwindler$ helm install prometheus stable/prometheus
Error: This command needs 1 argument: chart name

Ah ! Et oui, la commande est différente selon qu’on upgrade ou qu’on install une release. Pratique.

Vous allez me dire « bah, pourquoi tu ne fais pas un upgrade –install, comme ça la commande est la même que tu upgrade ou que tu installes ?

Tout simplement car cette commande ne marchait PLUS pendant longtemps (genre 2 ans), comme le témoigne cette issue sur Github et ce tweet rageur d’un certain zwindler

Enfin bon…

zwindler$ helm install --name prometheus stable/prometheus
Error: a release named prometheus already exists.

Là, par contre, on est d’accord que Helm se fiche vraiment de moi ?

Donc, dans ce genre de souci, vous pouvez sortir l’artillerie lourde avec le « –purge », qui fini par devenir la norme (en gros, je le mettais à chaque fois).

zwindler$ helm delete prometheus --purge
release "prometheus" deleted

Et là on peut réinstaller sa release…

zwindler$ helm install --name prometheus stable/prometheus -f prom-values-with-thanos.yaml
NAME: prometheus
LAST DEPLOYED: Thu Oct 10 15:12:39 2019
NAMESPACE: monitoring
STATUS: DEPLOYED

Bon… et la prochaine fois que vous voudrez mettre à jour les valeurs de votre déploiement, n’oubliez pas de refaire des « upgrade » et pas « install », sinon il va vous conseiller de la delete ;)

zwindler$ helm install --name prometheus stable/prometheus -f prom-values-with-thanos.yaml
Error: a release named prometheus already exists.
Run: helm ls --all prometheus; to check the status of the release
Or run: helm del --purge prometheus; to delete it

Et c’est pas fini !

Dans les bugs rigolos de Helm 2, on a aussi le flag DEBUG, souvent utilisé dans les Charts pour activer le mode debug du logiciel que vous essayez de déployer, qui est AUSSI utilisé par Helm pour passer en debug et qui vous crache du caca dans votre CI.

Client: &amp;version.Version{SemVer:"v2.4.1", GitCommit:"46d9ea82e2c925186e1fc620a8320ce1314cbb02", GitTreeState:"clean"}
2017/05/06 16:11:47 (0xc42088e210) (0xc4204be000) Create stream
2017/05/06 16:11:47 (0xc42088e210) (0xc4204be000) Stream added, broadcasting: 1
2017/05/06 16:11:47 (0xc42088e210) Reply frame received for 1
2017/05/06 16:11:47 (0xc4204be000) (1) Writing data frame
2017/05/06 16:11:47 (0xc42088e210) (0xc4204be140) Create stream
2017/05/06 16:11:47 (0xc42088e210) (0xc4204be140) Stream added, broadcasting: 3
...

github.com/helm/helm/issues/2401

Ah oui tient, c’est marrant ça, on devrait peut être changer DEBUG en HELM_DEBUG ?No shit, sherlock

Ou bien les ConfigMap trop grandes (lol) qui font planter tiller

[storage] 2020/01/14 15:00:16 getting release history for "airflow"
[storage/driver] 2020/01/14 15:00:16 create: failed to create: ConfigMap "airflow.v1" is invalid: []: Too long: must have at most 1048576 characters
[tiller] 2020/01/14 15:00:16 warning: Failed to record release airflow: ConfigMap "airflow.v1" is invalid: []: Too long: must have at most 1048576 characters
[kube] 2020/01/14 15:00:16 building resources from manifest
[kube] 2020/01/14 15:00:16 creating 21 resource(s)
[kube] 2020/01/14 15:00:18 beginning wait for 21 resources with timeout of 5m0s
[kube] 2020/01/14 15:00:20 Pod is not ready: airflow/airflow-worker-0
[kube] 2020/01/14 15:00:38 Pod is not ready: airflow/airflow-worker-0
[kube] 2020/01/14 15:00:40 Pod is not ready: airflow/airflow-worker-1
[kube] 2020/01/14 15:00:42 Pod is not ready: airflow/airflow-worker-1
[kube] 2020/01/14 15:00:44 Pod is not ready: airflow/airflow-worker-1
[kube] 2020/01/14 15:00:46 Pod is not ready: airflow/airflow-worker-1
[tiller] 2020/01/14 15:01:40 executing 0 post-install hooks for airflow
[tiller] 2020/01/14 15:01:40 hooks complete for post-install airflow
[storage] 2020/01/14 15:01:40 updating release "airflow.v1"
[storage/driver] 2020/01/14 15:01:40 update: failed to update: configmaps "airflow.v1" not found
[tiller] 2020/01/14 15:01:40 warning: Failed to update release airflow: configmaps "airflow.v1" not found

github.com/helm/helm/issues/1413

Ou enfin, les timeouts de tiller quand vous avez trop déployé (lol) et que du coup les commandes « helm list » timeout… ce qui nous avait obligé à installer un tiller par namespace et modifier notre CI pour gérer tout ce bazar.

Non, vraiment, Helm 2 est vraiment un chouette logiciel !

Kubernetes avec RancherOS et RKE – partie 1

Mon, 26 Oct 2020 07:45:00 +0000

RancherOS pour commencer

Pendant l’été, j’ai encore changé d’infra, avec un passage à un cluster Proxmox VE à 3 nœuds. Je reviendrais la dessus, mais la finalité c’est que j’ai eu (encore) l’envie de m’installer un petit cluster Kubernetes dans mes hyperviseurs.

Ceux qui me suivent depuis un moment savent que j’en ai déjà déployé des tonnes depuis le temps (k3s qui vient également de chez Rancher, mais aussi kubespray, kubeadm, aks, OVH, the hard way de kelsey hightower, …).

Du coup, plutôt que de gagner du temps et refaire quelque chose que je maîtrise déjà, je suis parti dans l’idée de tester quelque chose d’encore nouveau, deux produits de Rancher dont j’ai entendu parler : RancherOS + RKE !

L’idée dans cette première partie est de découvrir RancherOS, une des nombreuses solutions pour vos workload containerisés proposées par Rancher.

Mais c’est quoi RancherOS ?

RancherOS A lightweight, secure Linux distribution, built from containers to run containers well. RancherOS est donc un OS minimaliste contenant juste ce qu’il faut pour faire du Docker, configuré à l’aide de cloud-init et dans lequel la plupart des opérations de maintenances sont simplifiées. Quand je lis ça, je ne peux pas m’empêcher de repenser à CoreOS, qui faisait (fait) les mêmes promesses. N’ayant qu’installé et utilisé pendant peu de temps CoreOS, je ne serai pas capable de faire une comparaison des deux produits entre eux, mais la finalité est vraiment la même. Un point intéressant (je trouve) dans RancherOS est le fait que tous les services “techniques” nécessaires pour faire fonctionner correctement vos applications containerisés sont également des containers. RancherOS is the smallest, easiest way to run Docker in production. Every process in RancherOS is a container managed by Docker. This includes system services such as udev and syslog.

L’idée ici, c’est que tous ces services systèmes tournent dans un démon Docker séparé (pour plus de sécurité et éviter la suppression accidentelle).

Comment le déployer ?

Ça dépend. Et évidemment, ça dépend, ça dépasse.

Rancher a fait le choix (malin) de mettre le paquet pour faciliter le déploiement de leur RancherOS sur le plus de plateformes possibles.

Ainsi, vous retrouverez des processus de déploiement facilités pour la plupart des clouds providers public, mais aussi des images pour VMware, une image pour Rasberry Pi, Virtual Box ou Docker Machine. Il y a même de quoi booter en PXE pour ceux qui ont encore l’envie de faire ce genre de choses.

Dans mon cas, la seule solution à ma disposition pour KVM c’est d’utiliser l’ISO.

Première bonne nouvelle et première déconvenue

LA première bonne nouvelle, c’est qu’il existe un ISO tuné pour Proxmox VE, et ça c’est très cool.

Donc je DL l’ISO, créé une bête machine virtuelle sur mon cluster, dans lequel l’ISO est monté et roule ma poule ?

Ouais… presque !

You must boot with enough memory which you can refer to here.

Un point agaçant avec RancherOS est le minimum requirement en termes de mémoire. 1.25 Go pour un OS Linux soi-disant minimaliste (passé à 1 Go depuis la 1.5), la pilule a du mal à passer. Ok, je pinaille peut-être un peu, mais 1 Go c’est énorme quand on a prévu de lancer juste quelques petits containers comme des petits nginx ou des petits bouts de code python.

Il faut dire que Rancher nous a mal habitué avec k3s, leur Kubernetes modifié qui tourne avec quasiment pas de RAM au point de permettre de Kubernetes sur des RPi 1 ou en edge computing. Et là, avec 2 fois plus de RAM en requirement, j’ai que le démon Docker, même pas le kube qui va avec…

Du coup, le “RancherOS is the smallest, easiest way to run Docker in production”, bof…

Déployer en 5 minutes un cluster Kubernetes sur ARM avec k3s et Ansible

Rancher essaye de se raccrocher aux branches en vous linkant une doc permettant de construire soi-même une image custom nécessitant moins de RAM, mais bon… Le mal est fait, ils m’ont pas motivé à tester…

Déployer RancherOS sur Proxmox VE

Ok, assez discuté, maintenant on peut rentrer dans le vif du sujet. Sur notre hyperviseur préféré, on récupère l’ISO.

cd /var/lib/vz/template/iso
wget https://releases.rancher.com/os/latest/proxmoxve/rancheros.iso
--2020-08-10 15:00:26-- https://releases.rancher.com/os/latest/proxmoxve/rancheros.iso
Resolving releases.rancher.com (releases.rancher.com)... 104.26.12.240, 172.67.69.133, 104.26.13.240, ...
Connecting to releases.rancher.com (releases.rancher.com)|104.26.12.240|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 160432128 (153M) [application/x-iso9660-image]
Saving to: ‘rancheros.iso’
rancheros.iso 100%[===================>] 153.00M 42.3MB/s in 3.7s
2020-08-10 15:00:36 (40.9 MB/s) - ‘rancheros.iso’ saved [160432128/160432128]

La procédure d’installation officielle est disponible ici.

Grosso modo, on boot la VM, qui va configurer le serveur au minimum et permettre de se connecter avec l’utilisateur rancher sans mot de passe. L’idée est d’utiliser cet utilisateur pour finaliser l’installation avec ros install une fois la VM configurée.

The ros install` command orchestrates the installation from the rancher/os container. You will need to have already created a cloud-config file and found the target disk.

STOOOOOP

Si vous partez bille en tête comme moi et faites un ros install` sans lire la phrase en entier, vous vous retrouverez avec une VM sur laquelle vous ne pourrez pas vous loguer (voire sans réseau si vous n’avez pas de DHCP). C’est con.

The easiest way to log in is to pass a cloud-config.yml file containing your public SSH keys.

Cloud config

Ok, on va éviter de tous faire la même erreur. Voici maintenant le fameux prérequis, la documentation officielle qui parle de configuration/#cloud-config.

Si vous avez un doute sur certains paramètres, vous pouvez toujours utiliser la commande ros config` qui permet de récupérer les valeurs par défaut puis les setter.

On finalisera le tout en fusionnant la config actuelle avec un fichier YAML, ou alors on exportera la conf actuelle dans un autre fichier YAML.

Dans le cas d’un PoC, la plupart des valeurs qui vont nous intéresser sont simplement ce qui permet de setter l’IP et de configurer notre clé SSH pour pouvoir se connecter.

sudo ros config get rancher.network
dhcp_timeout: 0
dns:
nameservers: []
search: []
http_proxy: ""
https_proxy: ""
interfaces: {}
modem_networks: {}
no_proxy: ""
post_cmds: []
pre_cmds: []
wifi_networks: {}

Donc là, de base, bah ya rien.

Pourtant, si vous allez voir le fichier /var/lib/rancher/conf/cloud-config.yml, vous remarquerez qu’il y a pleeeeein de choses, plus ou moins utiles.

La page de doc qui nous intéressera donc dans ce cas est networking. Voici un exemple de commandes pour configurer une IP fixe (à remplacer par des valeurs qui ont du sens dans votre réseau, of course).

sudo ros config set rancher.network.interfaces.eth0.address 192.168.1.10/24
sudo ros config set rancher.network.interfaces.eth0.gateway 192.168.1.1
sudo ros config set rancher.network.interfaces.eth0.mtu 1500
sudo ros config set rancher.network.interfaces.eth0.dhcp false

A partir de ce moment là, vous avez accès au réseau depuis votre machine RancherOS, mais les modifications ne seront pas permanentes. On va donc exporter tout ça.

sudo ros config export
rancher:
environment:
EXTRA_CMDLINE: /init
network:
interfaces:
eth0:
address: 192.168.1.10/24
dhcp: false
gateway: 192.168.1.10
mtu: 1500
ssh_authorized_keys: []

Bon, et là vous voyez qu’il nous manque toujours la clé SSH.

Bonus clavier qwerty

Vous connaissez la différence entre un admin systèmes français débutant et un admin système français senior ?

If you call yourself a sysadmin and don’t know by heart the qwerty layout on an azerty keyboard, I just assume you are a junior.

(Pour ceux qui n’ont pas la blague, allez voir ce tweet de _oshell qui a bien backfired (lien mort) dans sa face)

Le senior, a force de bouffer des consoles à la con qui gèrent mal les différents layouts de claviers (parce que “hé, on s’en fout des gens qui ont pas de qwerty, on vient de la Silicon valley”), il connaît le qwerty par cœur.

Et ben là encore, ça n’a pas loupé. La console NoVNC de mon PVE, qui en plus n’avait le partage de presse-papier qui ne marchait pas.

Je veux bien être à l’aise en “blind qwerty sur azerty”, mais faut pas déconner, je suis pas senior au point d’être capable de copier une clé publique dans un YAML #trollface.

Donc pour ceux qui ne connaissent pas l’astuce, il est possible d’affecter temporairement un terminal série à votre VM de la façon suivante (voir doc Proxmox VE)

# qm set 100 -serial0 socket
update VM 100: -serial0 socket

A partir de là, vous devriez pouvoir accéder à un nouveau type de console dans Proxmox, qui devrait à la fois résoudre le problème de clavier qwerty ET le problème de presse-papier.

Cloud-config, suite

On récupère ce qu’on vient d’exporter et on ajoute notre clé comme nous le demande Rancher dans sa doc. Et avant de lancer l’install, on vérifie que notre cloud-config est valide

sudo ros config validate -i cloud-config.yml

Si la commande ne renvoie rien, c’est que c’est OK (pas super explicite mais bon why not). On passe donc à l’install :

sudo ros install -c cloud-config.yml -d /dev/sda
INFO[0000] No install type specified...defaulting to generic
Installing from rancher/os:v0.5.0
Continue [y/N]:
[...]
Continue with reboot [y/N]: y
INFO[0013] Rebooting

A partir de là, on peut (et on doit) se connecter en SSH sur la machine RancherOS (l’accès console n’est plus possible)

ssh -J proxmoxve rancher@192.168.1.10

Et si tout s’est bien passé, vous devriez pouvoir vous connecter !

Et maintenant, que vais-je fai-reuh ?

Ben déjà on peut regarder ce que RancherOS a activé comme “services” sur notre install Proxmox VE.

sudo ros service list
disabled amazon-ecs-agent
disabled container-cron
disabled open-iscsi
disabled zfs
disabled kernel-extras
disabled kernel-headers
disabled kernel-headers-system-docker
disabled open-vm-tools
disabled hyperv-vm-tools
enabled qemu-guest-agent
disabled rancher-server
disabled rancher-server-stable
disabled amazon-metadata
disabled volume-cifs
disabled volume-efs
disabled volume-nfs
disabled modem-manager
disabled waagent
disabled virtualbox-tools
disabled pingan-amc

Globalement, pas grand chose. La seule chose activée est le qemu-guest-agent, ce qui est utile puisque nous avons une effectivement une VM QEMU dans ce cas précis. Quant à vos containers Docker, vous pouvez vérifier qu’ils sont bien séparés des containers docker servant au fonctionnement de RancherOS avec les commandes suivantes :

Les containers “systèmes”

[rancher@rancher ~]$ sudo system-docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
1e059e78c17e rancher/os-docker:19.03.11 "ros user-docker" 12 minutes ago Up 12 minutes docker
ba43a0648227 rancher/os-qemuguestagent:v2.8.1-2 "/usr/bin/ros entr..." 12 minutes ago Restarting (1) 34 seconds ago qemu-guest-agent
d9ad607221fa rancher/os-console:v1.5.6 "/usr/bin/ros entr..." 12 minutes ago Up 12 minutes console
ad0197c79ff2 rancher/os-base:v1.5.6 "/usr/bin/ros entr..." 12 minutes ago Up 12 minutes ntp
538ccf5eb624 rancher/os-base:v1.5.6 "/usr/bin/ros entr..." 12 minutes ago Up 12 minutes network
f389c6b0b40e rancher/os-base:v1.5.6 "/usr/bin/ros entr..." 12 minutes ago Up 12 minutes udev
b51deb379bf2 rancher/container-crontab:v0.4.0 "container-crontab" 12 minutes ago Up 12 minutes system-cron
59441adcc016 rancher/os-syslog:v1.5.6 "/usr/bin/entrypoi..." 13 minutes ago Up 12 minutes syslog
120df7cc2492 rancher/os-acpid:v1.5.6 "/usr/bin/ros entr..." 13 minutes ago Up 12 minutes acpid

Vos containers :

[rancher@rancher ~]$ docker container ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

Les containers “systèmes” sont bien distincts des containers docker “utilisateurs”. La promesse d’isolation Docker infra vs Docker appli est bien tenue.

Mon avis

A voir à l’usage, mais je ne suis pas hyper convaincu.

D’abord, en termes d’OS minimalistes, on a quand même vu mieux. Et d’ailleurs, les gens chez Rancher le savent puisqu’ils se sentent obligés de s’en justifier…

Plus grave, l’UX est quand même super bof. J’ai l’habitude d’installer des softs mais je me suis quand même pris la tête avec le cloud-config assez moyennement documenté, et en plus, à faire DANS une console (et la galère QWERTY/AZERTY associée).

“Et c’est pas fini”, comme dis la pub.

Je vous l’ai dis, mon objectif est d’avoir un cluster Kubernetes installé par RKE. Or, il n’est pas trivial d’utiliser RancherOS comme OS pour hoster un Kubernetes déployé avec RKE. Vous verrez dans la partie 2 que ça n’a pas été une partie de plaisir…

Un comble pour 2 produits de la même boite censé vous simplifier l’administration de Docker/Kube…

Et plus grave encore, c’est que j’ai du mal à voir pour qui ce genre de distribs apporte de la valeur. C’est d’ailleurs pour cette même raison pour laquelle je n’avais pas poussé l’expérimentation très loin avec CoreOS. En tant qu’admin, je suis forcément frustré par un OS où je n’ai pas/peu la main.

J’aime bien ce qu’ils font chez Rancher. Mais je ne sais pas répondre à la question Pourquoi RancherOS ? On pourrait se dire que pour une équipe de développeurs en mode startup qui doit sortir son MVP en peu de temps, ça peut être cool.

Mais même là, j’ai des doutes.

Si ces gens là veulent VRAIMENT s’abstraire d’Ops (voir mon avis sur la question dans Au secours, le métier d’Ops va disparaître !), ils partiront sur d’autres types de technos (Kubernetes managé, Serverless, No code ?).

Si vous voyez une raison que j’aurais loupé, n’hésitez pas à venir en parler en commentaire ou via les RS, car là je vois pas…

En attendant la partie sur RKE, have fun :)

Echec déploiement package OVF: Cette tâche a été annulée par un utilisateur

Mon, 30 Mar 2015 21:18:12 +0000

[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 :

KB VMware (lien mort, comme d’habitude)
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.