Distribution EOLE

Réponse de Daniel :

[Il] faut monter un test pour voir si c’est facilement reproductible

• https://dev-eole.ac-dijon.fr/jenkins/job/2.8.1/job/test-importation-acahapy-2.8.1-amd64
• https://dev-eole.ac-dijon.fr/jenkins/job/2.9.0/job/test-importation-acahapy-2.9.0-amd64
• https://dev-eole.ac-dijon.fr/jenkins/job/2.10.0/job/test-importation-acahapy-2.10.0-amd64

Le problème se pose si tu as une VM démarré et que tu redemarre Hapy (ce qui arrive presque toutes les semaines avec la mise à jour).

Alors là il faut aller manuellement sur chaque VM désactiver/reactiver le réseau.

Dans les tests j'ai pas analysé mais je ne vois pas de redémarrage du Hapy après avoir déployer la VM. Je viens de voir que tu as modifié le test dans ce sens.

je vois que dans diagnose on regarde le STATE et pas le LCM_STATE
si j'en crois https://docs.opennebula.io/6.10/integration_and_development/references/vm_states.html
une machine dans l'état UNKNOWN est considéré comme active à mon avis il faudrait plutot regarder LCM_STATE et qu'il soit à RUNNING

Avec un aca.hapy-2.9.0-instance-AvecImport re-démarré, ça donne :

root@hapy:~# su oneadmin -s /bin/sh -c 'onevm show 0 | grep '\''^STATE'\''  | cut -d: -f2 | tr -d '\'' '\'''
ACTIVE
root@hapy:~# su oneadmin -s /bin/sh -c 'onevm show 0 | grep '\''^LCM_STATE'\''  | cut -d: -f2 | tr -d '\'' '\'''
RUNNING

Je pense que le simple fait de prendre en compte le LCM_STATE ne suffit pas (il faut déjà que je reproduise le cas pour avoir plus d'informations), a mon humble avis, il faut revoir complètement la gestion des reboots de VM qui pose un problème depuis bien longtemps.

Premier soucis lié au partitionnement des VMs hapy sur le one. Le shutdown du serveur timeout et on obtient un message d'erreur sur sunstone sur chaque VM après redémarrage de hapy :

 bash: ligne 2: /var/tmp/one/vmm/kvm/save: Aucun fichier ou dossier de ce nom ExitCode: 127 

After=var-tmp.mount

Cependant, dans cet état les VMs sont bien démarrées.

Après avoir un coup de chance et un redémarrage sans timeout, je me retrouve dans l'état suivant :
- j'ai 2 VMs démarrées
- je redémarre hapy
- les 2 VMs sont données comme démarrées par onevm list ou sunstone. Sauf qu'impossible d'y accéder par VNC.
Au bout de 5min, j'obtiens les logs suivants :

Mon Jan  5 11:51:04 2026 [Z0][LCM][I]: VM running but monitor state is POWEROFF
Mon Jan  5 11:51:04 2026 [Z0][VM][I]: New LCM state is SHUTDOWN_POWEROFF
Mon Jan  5 11:51:04 2026 [Z0][VM][I]: New state is POWEROFF
Mon Jan  5 11:51:04 2026 [Z0][VM][I]: New LCM state is LCM_INIT

Au shutdown, il semble que ce soit systemd qui arrête les VMs avant que le service onenode ne s'exécute.

janv. 12 16:22:41 hapy systemd[1]: machine-qemu\x2d1\x2done\x2d2.scope: Failed to kill control group /machine.slice/machine-qemu\x2d1\x2done\x2d2.scope, ignoring: Operation not supported
janv. 12 16:22:41 hapy systemd[1]: machine-qemu\x2d1\x2done\x2d2.scope: Killing process 6363 (qemu-system-x86) with signal SIGKILL.
janv. 12 16:22:41 hapy systemd[1]: machine-qemu\x2d1\x2done\x2d2.scope: Failed to kill control group /machine.slice/machine-qemu\x2d1\x2done\x2d2.scope, ignoring: Operation not supported
janv. 12 16:22:41 hapy systemd[1]: machine-qemu\x2d1\x2done\x2d2.scope: Deactivated successfully.
janv. 12 16:22:41 hapy systemd[1]: Stopped Virtual Machine qemu-1-one-2.

-> Soit il faut empêcher systemd de manipuler les VMs, soit il faut modifier onenode pour qu'il ne demande pas à opennebula de suspend les VMs (et attendre qu'elles soient suspend).

Difficile de court-circuiter les .scopes machine-qemu..one.. Peut-être qu'une solution est de rajouter un service en dépendance de virt-guest-shutdown.target.
Une autre solution serait, au démarrage, de poweroff les VMs puis de les resume.