À l'agrandissement, on indique désormais l'espace libre de l'hôte et la
taille virtuelle MAX « soutenable » ≈ (taille réelle actuelle + libre
hôte) — affichée AVANT la saisie pour guider le choix. Si la cible la
dépasse, avertissement NON bloquant : le qcow2 est creux, donc OK tant que
la VM ne remplit pas, mais au-delà l'hôte tomberait à court d'espace.
Ex. : réel 115G + libre 30G -> max soutenable ~145G ; viser 190G affiche
« dépasse de ~45G — surallocation ». L'opération n'est pas bloquée.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sur un hôte en français, « virsh domstate » renvoie « en cours d'exécution »
au lieu de « running ». Le test « state == "running" » échouait donc :
l'agrandissement à chaud tombait dans la branche « qemu-img resize » (au
lieu de « virsh blockresize ») sur une VM ALLUMÉE -> « Failed to get write
lock ».
On force désormais LC_ALL=C / LANG=C (via _qemu_c_env) sur tous les outils
dont on PARSE la sortie, pour avoir l'anglais quelle que soit la locale :
virsh domstate/domname/dominfo/domblklist/list, sgdisk -i, dumpe2fs,
resize2fs -P (todo.py) et virsh list --all (dashboard). Cela répare aussi,
en locale fr, la détection d'état (pause/éteinte), l'analyse des infos
avancées (CPU/RAM) et le parsing de la réduction (partition/GPT).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Trois améliorations autour de la sauvegarde de disque à la réduction :
- La sauvegarde .bak n'est plus systématique : on DEMANDE (défaut OUI)
« Sauvegarder le disque avant réduction ? ». Si non, avertissement (un
échec pourrait casser le disque, pas de restauration possible).
- À la FIN, après avoir proposé de démarrer la VM (donc après test manuel
possible), on propose d'EFFACER la sauvegarde (défaut NON -> on la garde
par prudence).
- « Nettoyer QEMU » détecte désormais les sauvegardes *.qcow2.bak (libellé
« sauvegarde de disque (redim.) ») et permet de les effacer.
_qemu_shrink_revert gère l'absence de sauvegarde (avertit de lancer fsck
au lieu de restaurer). Validé de bout en bout sur image jetable.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
« Partition à réduire introuvable » sur une vraie VM : _qemu_root_part
parsait lsblk en positionnel et EXIGEAIT 4 colonnes. Juste après le connect
nbd, le FSTYPE n'est pas encore en cache -> colonne VIDE -> 3 tokens ->
toutes les partitions étaient ignorées. (Le test initial passait car le FS
avait eu le temps d'être détecté.)
- lsblk -P (paires clé="valeur") : robuste aux colonnes vides ; on repère
la partition par TYPE="part" et on sonde le FSTYPE via blkid si absent.
- _qemu_nbd_connect attend l'APPARITION des sous-périphériques nbdNpM
(jusqu'à ~15 s) avant de rendre la main.
- partprobe silencieux (capture) -> plus de spam « Invalid argument during
seek » pendant la réparation GPT.
Validé sur image jetable au layout cloud (p1 root + p14 bios + p15 ESP),
détection immédiate après connect : 25G -> 15G, GPT « No problems found »,
partitions préservées, fsck propre.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
La réduction « sûre » via virt-resize ne marchait pas : (1) j'utilisais
« virt-filesystems -b » (option INEXISTANTE -> aucune partition détectée ->
« abandon »), et (2) libguestfs est inutilisable ici (aucun vmlinuz dans
/boot -> l'appliance supermin échoue). La VM restait donc à 25G.
Réécriture SANS libguestfs, avec des outils de base présents et éprouvés
(qemu-nbd, e2fsck, resize2fs, sgdisk, parted/partprobe) :
1. copie .bak AVANT toute modification ;
2. nbd + détection de la racine (plus grosse partition, ext seulement) ;
3. e2fsck -> resize2fs (FS) -> sgdisk réécrit la partition en PRÉSERVANT
type/UUID/nom (PARTUUID intact) -> qemu-img --shrink (conteneur) ->
sgdisk -e (GPT de secours) -> fsck final ;
4. en cas d'échec à N'IMPORTE quelle étape : restauration depuis .bak
-> corruption impossible.
Validé de bout en bout sur une image jetable (GPT + ext4, racine à offset
élevé, 800M de données) : 25G -> 15G, GPT « No problems found », fsck
propre, UUID préservé, données intactes.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Si le dashboard se ferme (bug, sortie), on peut désormais le ROUVRIR sur un
run passé pour reprendre l'analyse. Nouvelle entrée [11] du menu QEMU :
« 📈 Rouvrir le suivi d'installation (dernier run / historique) ».
- mon.list_install_runs() : liste les runs (~/.erplibre/qemu-install/*/
session.json) triés du plus récent au plus ancien.
- _qemu_reopen_monitor : affiche l'historique (VM par run), choix (défaut =
le dernier), puis run_monitor(session.json) rouvre le dashboard.
- « Lister les images » passe de [11] à [12] ; config -> 13+.
Validé : 20 runs listés, dashboard reconstruit (titre + 5 VM) depuis un
session.json passé.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
« Suivi interactif (dashboard) ? » répondait NON par défaut (réponse vide).
Le défaut est désormais OUI : nouveau helper _is_yes_default_yes (vide = oui)
et libellé « (O/n, défaut : oui) » / « (Y/n, default: yes) ».
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
virt-resize/virt-filesystems (requis pour la réduction SÛRE de disque) sont
des binaires SYSTÈME (OCaml), pas des paquets Python : ils ne peuvent pas
vivre dans .venv.erplibre. On les ajoute donc au jeu de paquets système du
profil « ERPLibre Déploiement » (à côté de qemu/libvirt/virtinst) :
apt libguestfs-tools · dnf guestfs-tools · pacman libguestfs.
Ainsi tout hôte provisionné avec ce profil peut réduire un disque sans
risque. (La commande de redimensionnement propose déjà d'installer
libguestfs à la demande si absent.)
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Réduire avec « qemu-img resize --shrink » tronquait le conteneur qcow2 SANS
réduire le FS/partition/GPT invités : partition racine tronquée + GPT de
secours perdue -> dracut-initqueue en échec, OS non bootable.
Désormais la réduction passe par virt-resize (libguestfs) qui réduit
proprement système de fichiers + partition + GPT :
- _qemu_safe_shrink : écrit dans une NOUVELLE image (qemu-img create +
virt-resize --shrink <partition>), et ne remplace l'originale (mv) QUE si
virt-resize réussit. En cas d'échec/refus, le disque d'origine reste
INTACT (impossible de corrompre). Sauvegarde conservée en .bak.
- _qemu_largest_partition : détecte la partition racine (la plus grosse) via
virt-filesystems.
- _qemu_install_libguestfs : propose d'installer libguestfs-tools si absent ;
sinon on ABANDONNE (on ne tronque jamais).
- _qemu_offer_start extrait (redémarrage après extinction).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Après un shrink, « Démarrer la VM » faisait « virsh start <id> » : une fois
la VM éteinte, l'ID numérique disparaît -> « failed to get domain 32 ».
On résout désormais le NOM canonique dès le début de _qemu_resize_disk
(VM encore allumée, ID résoluble) et on l'utilise partout, y compris pour
le redémarrage final. Plus de dépendance à l'ID une fois la VM arrêtée.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Le choix du navigateur propose désormais « [i] Installer un autre
navigateur » en plus des navigateurs déjà installés. L'option ouvre le
sous-menu d'installation (choix w3m/lynx/links/elinks, commande adaptée à
l'OS, validation), même s'il existe déjà un navigateur.
Le flux d'installation est extrait dans _qemu_install_cli_browser
(réutilisé quand aucun navigateur n'est présent ET via l'option [i]).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Le navigateur ne faisait qu'imprimer sans réagir au clavier : la commande
passait par exec_command_live, qui exécute avec stdout=PIPE (et sans stdin
terminal) -> un navigateur texte (w3m/elinks) n'a pas de TTY interactif.
On lance désormais le navigateur avec os.system(), qui hérite du vrai
terminal (stdin/stdout/stderr) — même principe que le suivi d'installation
(TUI) qui l'appelle dans self.suspend(). Ici, en CLI simple, aucun suspend
n'est nécessaire.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Nouvelle entrée [10] dans « Gérer » du menu QEMU/KVM : 🧪 Tester une VM.
Elle liste les VM, demande laquelle, résout son IP puis ouvre
http://IP:8069 (Odoo) dans un navigateur web EN LIGNE DE COMMANDE choisi
par l'utilisateur.
- _qemu_test_vm : résolution d'IP (_qemu_vm_ip), lancement du navigateur,
message d'aide si la page ne s'affiche pas (Odoo pas démarré / réseau).
- _qemu_choose_cli_browser : liste les navigateurs CLI installés et laisse
choisir ; si aucun, propose d'en installer un (réutilise CLI_BROWSERS /
INSTALLABLE_BROWSERS / browser_install_command de qemu_install_monitor).
- « Lister les images » passe de [10] à [11] ; les entrées de config
suivent à 12+ (branche else inchangée via la liste `real`).
Validé : rendu du menu, choix du navigateur ([2]->elinks, vide->w3m).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Suivi d'installation (qemu_install_monitor.py) :
- Table VM/État LISIBLE : largeurs de colonnes fixes (VM 26, ⚠ 4, État 12,
Durée 7, Disque 8) -> l'État n'est plus tronqué à 3-4 caractères
(« ❌ effacée », « ⏸ en pause » lisibles) ; table défilable (overflow-x,
height 1fr) pour les longs noms et les gros parcs.
- « w » web : offre désormais la LISTE des navigateurs CLI installés
(_choose_browser) pour choisir lequel utiliser, + option [i] installer.
Déploiement (deploy_qemu.py) :
- guest-exec AUTORISÉ : on vide la liste de blocage de qemu-ga
(block-rpcs/blacklist vides — pas allow-rpcs qui est une liste BLANCHE et
casserait les autres RPC), + neutralise /etc/sysconfig/qemu-ga (Fedora).
Installation (todo.py) :
- Profils AVEC Odoo (install_odoo*) UNIQUEMENT : Odoo est enregistré comme
service systemd (erplibre.service, inspiré de script/systemd/
install_daemon.sh) puis enable --now. Pas pour ERPLibre seul / mobile /
Déploiement.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Provisioning (deploy_qemu.py) :
- qemu-guest-agent installé + activé dans le runcmd cloud-init (APRÈS
sshd, « || true » : ne bloque pas le boot si le réseau est lent).
- Canal virtio org.qemu.guest_agent.0 ajouté à virt-install : virsh peut
piloter la VM SANS réseau.
- Extension du FS invité (todo.py) : nouveau tier AGENT INVITÉ
(_qemu_guest_exec via qemu-agent-command guest-exec) entre SSH et la
console série -> étend le FS même sans IP.
Suivi d'installation (qemu_install_monitor.py) :
- Détection d'erreurs dans le log à la complétion (succès OU échec) en
réutilisant la logique de script/test/run_parallel_test.py (sous-chaîne
error/warning + listes d'ignore). Nouvelle colonne « ⚠ » À GAUCHE d'État
(⚠N erreurs / ⚡N avert. / ✓ propre).
- Sommaire de stats EN CHIFFRES (📊 total · ✅ · ❌ · ⏳ · ⏸ · 🗑 · ⚠ · ⚡) ;
CLIC pour déplier le détail (VM en erreur + durées).
- Boutons « p » Pause tout (virsh suspend des VM running) et « o »
Reprendre tout (virsh resume) — les logs continuent (offsets conservés).
Validé headless : succès-avec-erreur -> ⚠1, stats/détail, pause du parc.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Trois améliorations QEMU :
- Extension du FS invité robuste : résolution d'IP avec BATTEMENT
(_qemu_resolve_ips, parallèle, boot émulé lent) au lieu d'un timeout
court ; en cas d'absence d'IP ou d'échec SSH, repli sur la CONSOLE
SÉRIE avec la commande growpart/resize prête à coller (login
erplibre/erplibre). Commande factorisée dans _GROW_FS_REMOTE.
- Temps estimés PAR VERSION : nouveau mon.avg_by_version(distro, version)
et _qemu_stat_avg("version", v, distro) -> suffixe « · ~46s moy (1) »
dans les listes de versions (prompt simple + granulaire).
- i18n : « Versions for » n'avait AUCUNE traduction (restait en anglais).
Ajout FR « Versions des » (+ « Version des ») et capitalisation de la
distro -> « Versions des Ubuntu : ».
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Deux points :
- Fil d'Ariane depuis la télémétrie : une commande lancée DEPUIS le TUI de
télémétrie ne passait par aucun menu, donc son chemin n'était jamais
affiché. On imprime désormais « 📍 TODO › … › <commande> » (dernier
segment traduit + icône) avant l'exécution, et on enregistre le chemin.
- Arrêt de VM (réduction disque) par SIGNAL : virsh shutdown --mode
acpi,agent (bouton ACPI puis agent invité) au lieu d'un arrêt implicite.
Pendant l'attente, on affiche un compte à rebours du timeout
(« ⏳ arrêt en cours… NNN s restantes ») et le délai max au départ.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Après « virsh list --all », le menu propose désormais :
[1] Infos avancées (vCPU, RAM, disque)
[2] Changer l'état d'une ou plusieurs VM
[Entrée] Rien
Changement d'état (_qemu_change_state) :
- Saisie d'une liste de VM séparée par des virgules (noms ou ID, résolus
via _qemu_domname et validés contre les VM existantes).
- Choix de l'état cible : Ouvrir (start) ou Fermer (shutdown).
- DOUBLE validation (« Appliquer : … ? » puis « Confirmer pour de vrai ? »)
avant d'exécuter virsh start/shutdown sur chaque VM.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Si la VM a dû être éteinte pour la réduction, on le NOTE (« La VM a été
éteinte pour le redimensionnement. ») puis on demande (o/N) si on veut la
redémarrer (virsh start sur le nom canonique). Si la VM était déjà éteinte
ou n'a pas eu besoin de l'être (agrandissement à chaud), on ne demande
rien : drapeau was_shut_down positionné uniquement après un arrêt effectif.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Avant, réduire le disque d'une VM allumée affichait seulement « Éteignez
la VM » puis abandonnait. Désormais on DEMANDE (o/N) si on veut l'éteindre
et réessayer :
- _qemu_shutdown_wait : arrêt ACPI gracieux (virsh shutdown), attente
jusqu'à « shut off » (timeout 120s), puis propose un arrêt forcé
(virsh destroy) si l'arrêt traîne.
- _qemu_domname : résout un ID numérique en nom canonique — l'ID
disparaît une fois la VM éteinte, le polling doit utiliser le nom.
Validé : domname(14) -> erplibre-ubuntu-2004.
- Tous les nouveaux prompts affichent la valeur par défaut (o/N).
Une fois éteinte, la réduction (qemu-img resize --shrink) se poursuit
automatiquement après confirmation du risque.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Après « sudo virsh list --all », le menu propose désormais (o/N) un
tableau détaillé par VM : état, vCPU, RAM allouée (Max memory), taille
disque virtuelle et réelle (qemu-img info -U, lit même VM allumée), plus
l'espace total/libre/utilisé du stockage des images (shutil.disk_usage).
- _qemu_list_vms(ask_advanced=False) : seul le menu [4] prompte ;
les appels internes (IP, console, resize, delete) restent inchangés.
- Helpers _qemu_dominfo (vcpu + Max memory) et _qemu_disk_sizes
(virtuel + réel, -U). Validé en réel : 8 vCPU / 8.0G / 30.0G / 2.5G.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
qemu-img info échouait (« Failed to get shared write lock ») sur une VM
running car libvirt tient le lock d'écriture : la taille virtuelle lue
tombait à 0.0 G, et « -10G » donnait alors 0-10 = -10 → « Taille invalide ».
- Ajout de -U (--force-share) aux deux appels qemu-img info (affichage +
_qemu_disk_virtual_bytes) : lecture seule sûre même VM allumée.
- Garde-fou : si la taille reste illisible (0), on abandonne avec un
message clair au lieu de calculer une cible négative.
Le redimensionnement lui-même était déjà correct (virsh blockresize à
chaud si running, qemu-img resize si éteinte) — pas besoin d'éteindre la
VM pour AGRANDIR. Validé : lecture -U renvoie 30.0 G sur une VM running.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
L'historique d'installation est désormais enregistré dans un fichier DÉDIÉ
.venv.erplibre/qemu_install_stats.json (repli ~/.erplibre) : chaque run garde
distro + version + architecture + durée + horodatage (500 derniers).
- record_duration(distro, version, arch, secs) enregistre le run (appelé par
le dashboard à la complétion d'une VM).
- Menus de sélection enrichis : chaque architecture et chaque distribution
affiche la DURÉE MOYENNE d'install historique « · ~5m moy (3) » quand la
donnée existe. La DERNIÈRE install (distro version [arch] — durée) est
rappelée en tête du déploiement.
- eta_reference lit désormais les runs (médiane par arch, repli global).
Nouveaux helpers : avg_by_arch, avg_by_distro, last_run.
Validé : enregistrement + moyennes (amd64 ~5m (2), ubuntu ~13m (3)),
dernière install affichée, distros sans données masquées.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Quand on installe ERPLibre sur une/des VM, on choisit désormais CE qu'on
installe (au lieu de forcer install_odoo_18) :
ERPLibre + Odoo 18/17/16/15/14/13/12 (make install_os && make install_odoo_X)
ERPLibre + toutes les versions Odoo (make install_odoo_all_version)
ERPLibre seulement (sans Odoo) (./script/install/install_erplibre.sh)
ERPLibre mobile (home) (./mobile/install_and_run.sh)
ERPLibre Déploiement (+ QEMU + dev) (install_dev + qemu/libvirt/virtinst)
_qemu_pick_install_profile renvoie la commande finale ; _qemu_erplibre_remote_cmd
l'exécute dans ~/git/erplibre ; le profil est threadé aux installeurs
(monitoré + streamé). Cibles make vérifiées dans les Makefiles.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Après exécution d'une commande choisie dans la télémétrie, on propose de
REVENIR (r) ou de quitter. En revenant, la vue ET la position du curseur
sont RESTAURÉES (chemin porté par chaque nœud/carte ; run_tui prend/rend un
`state`).
- Vue Kanban : F4 fait défiler la DISPOSITION —
columns (une rangée de colonnes) / swimlanes (une rangée par menu de
niveau 1) / grid (grille 3 colonnes). F3 bascule Arbre/Kanban.
Validé headless : F3/F4 cyclent les dispositions, sélection -> action+état,
relance avec `state` -> curseur restauré sur le bon nœud.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Le TUI de télémétrie devient aussi un LANCEUR, avec deux vues :
- Sélectionner une COMMANDE (feuille de l'arbre, ou carte du Kanban) +
Entrée -> le TUI se ferme et la commande est EXÉCUTÉE (getattr(self, méthode)
(**kwargs)). Les kwargs littéraux sont extraits du code (ex. Aperçu ->
_qemu_deploy(dry_run=True)), donc la commande est rejouée à l'identique.
- Vue KANBAN : une colonne par menu contenant des commandes (issu du code),
cartes = commandes exécutables + compteur de visites du menu.
- F3 bascule entre vue Arbre et vue Kanban. Résumé mis à jour (Entrée =
exécuter, F3 = vue).
_dispatch capture désormais (méthode, kwargs) ; les feuilles de l'arbre
portent la méthode en data ; run_tui renvoie (méthode, kwargs) à exécuter.
Validé headless : 11 colonnes Kanban, kwargs (dry_run/production_ready)
capturés, bascule F3, capture de l'action à exécuter.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Nouvelle entrée « [5] Télémétrie de navigation (TUI) » dans le menu principal.
- Enregistrement : Todo._menu_header (seul constructeur du fil d'Ariane)
appelle todo_telemetry.record(fil) à chaque affichage de menu. Dédup des
ré-affichages consécutifs -> on ne compte que les TRANSITIONS de
navigation. Persistant dans ~/.erplibre/todo_telemetry.json. Best-effort :
ne casse jamais la navigation.
- Visualisation : todo_telemetry.run_tui() ouvre un TUI Textual affichant
l'ARBRE des fonctionnalités visitées (chaque nœud = un menu, avec son
nombre de visites), trié par usage décroissant. Touches : q (quitter),
r (réinitialiser), e (tout déplier). Sommaire : total navigations + menus.
Validé headless : enregistrement + dédup, arbre imbriqué à compteurs,
montage du TUI, peuplement, touches.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Nouvelle entrée dans le menu QEMU/KVM (section Gérer). Elle :
- affiche le disque principal (qcow2 via domblklist) + « qemu-img info »
(taille virtuelle + réelle) et l'état de la VM ;
- demande +NG (agrandir), -NG (réduire) ou NG (taille cible) ;
- applique : agrandissement À CHAUD si la VM tourne (virsh blockresize),
sinon qemu-img resize ; réduction via qemu-img resize --shrink (VM éteinte
obligatoire + avertissement fort : le FS invité n'est PAS réduit, risque
de perte de données) ;
- propose ensuite d'étendre le FS invité via SSH (growpart + resize2fs /
xfs_growfs / btrfs, device et type de FS détectés).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sur un gros parc (30 VM, ~18 émulées), la résolution d'IP « bloquait » 10 min
en silence sur les VM lentes. Trois causes traitées :
- Joignabilité par PING (ICMP) d'abord, TCP:22 en repli. Le ping répond dès
que le réseau de la VM est up, BIEN AVANT sshd : on ne retenait pas une VM
qui a déjà son IP juste parce que sshd (lent en émulation) n'était pas prêt.
Le ping distingue toujours le bail actif (répond) du bail périmé (non).
- IP cherchée sur PLUSIEURS sources : lease (dnsmasq), agent (qemu-guest-
agent DANS la VM) et arp (table ARP hôte). Le bail dnsmasq peut être vide
sous forte charge alors que la VM a une IP (constaté sur ce parc).
- BATTEMENT toutes les 30 s listant les VM encore en attente + timeout PAR VM
ramené à 5 min (au lieu de 10) dans la phase de résolution -> plus de
silence prolongé, et on n'attend pas indéfiniment une VM sans IP.
NB : déployer la matrice complète (30 VM dont ~18 émulées TCG) sature un seul
hôte ; certaines VM émulées n'obtiennent pas de bail DHCP à temps (limite de
capacité, pas un bug). La résolution dégrade désormais proprement.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Améliore le suivi du déploiement multi-VM :
- Compteur de COMPLÉTION devant chaque résultat (« [1/26] », « [2/26] »… =
ordre où les tâches TERMINENT), en plus de l'ID de préparation stable
(« [7/26] ») — utile car l'exécution parallèle rend les résultats
désordonnés.
- Temps d'exécution PAR ÉTAPE : durée de chaque VM (déploiement, résolution
d'IP) + bilan de phase (« Bilan déploiement : 24 OK, 2 en échec, 26 VM,
3m10s » ; « IP résolues : 25/26 (2m). »).
- SOMMAIRE TOTAL encadré en fin de flux (VM déployées, total avec
existantes, temps total).
Helper _fmt_dur (« 45s » / « 2m05s »).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sur un gros parc (ex. 26 VM), on ne voyait ni combien de VM allaient être
déployées ni lesquelles étaient en cours (résultats parallèles dans le
désordre). Deux améliorations :
- Le prompt de parallélisme affiche le NOMBRE de VM à déployer :
« Déploiements en parallèle (défaut : 24, 26 VM) : ». Pour cela, la
séparation à-créer / déjà-existantes est faite AVANT le prompt (on connaît
le vrai compte).
- Chaque VM reçoit un ID « k/N » suivant l'ordre de préparation, affiché
dans les résultats de déploiement (« ✅ [3/26] nom ») et dans la résolution
d'IP (« [5/30] nom : ip »). L'ID reste stable même si les résultats
reviennent dans le désordre -> on suit lesquelles sont traitées.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Le menu QEMU avait deux commandes de déploiement redondantes : [1] « Déployer
une VM » (mono, noms/ressources personnalisés) et [4] « Déployer l'infra »
(multi, matrice distro×version×archi). Elles sont FUSIONNÉES en une seule,
[1] « Déployer une ou plusieurs VM » (_qemu_deploy), qui gère aussi bien 1 VM
que N, avec :
- renommage GRANULAIRE des VM à la demande (_qemu_customize_names) : noms
auto par défaut, on en renomme certains par numéros séparés de virgules ;
- multiplicateur de ressources (x1..x4) déjà présent ;
- aperçu dry-run ([2]) qui passe par le même flux et imprime les commandes
deploy_qemu (--dry-run) via le helper partagé _qemu_build_deploy_parts.
Menu simplifié : [1] Déployer une/plusieurs VM, [2] Aperçu (dry-run),
[3] Télécharger une image, puis Gérer/Catalogue renumérotés. Code mort retiré
(_qemu_deploy_vm, _qemu_prompt_arch, _normalize_disk_size,
_qemu_offer_ssh_config).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Le menu Deploy listait 11 entrées « SSH - … » à plat, ce qui le surchargeait.
Elles sont déplacées dans un sous-menu « SSH (hôte distant)… »
(prompt_execute_deploy_ssh), comme le sous-menu QEMU. Le menu Deploy tient
désormais en 5 entrées :
── Local ──
[1] Cloner ERPLibre localement
[2] Configurer sshfs
── Distant & services ──
[3] SSH (hôte distant)… -> sous-menu (11 opérations SSH)
[4] NTFY
[5] QEMU/KVM…
Le fil d'Ariane affiche « TODO › Execute › Deploy › SSH » dans le sous-menu.
Les libellés et actions SSH sont inchangés (traductions réutilisées).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Avant le déploiement infra, on demande un multiplicateur de ressources :
x1 (minimum catalogue) .. x4. Il multiplie la RAM (base = minimum de la
version) et les vCPU (base 2), en bornant les vCPU au nombre de cœurs de
l'hôte et en signalant si la RAM totale dépasse la RAM libre.
- Le prompt affiche les ressources de l'hôte (vCPU, RAM libre) et, pour
chaque multiplicateur, le total RAM + vCPU/VM avec un ⚠ si ça dépasse.
- Le plan reflète les ressources effectives (vCPU + RAM×mult par VM).
- Les jobs passent --memory et --vcpus effectifs à deploy_qemu (avant,
l'infra laissait le minimum catalogue + 2 vCPU par défaut).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Après un déploiement infra, la résolution d'IP tournait EN SÉRIE (boucle
ssh_config puis install), jusqu'à 10 min par VM émulée, SANS aucune sortie :
le dashboard « n'ouvrait jamais » (impression de blocage), d'autant qu'une
VM qui ne boote pas (IP jamais attribuée) bloquait tout le reste.
Fix : _qemu_resolve_ips résout les IP de toutes les VM EN PARALLÈLE, avec
progression affichée par VM, une seule fois, réutilisée pour ~/.ssh/config
ET l'installation (plus de double résolution). _qemu_install_erplibre_*
acceptent une IP/ip_map déjà résolue.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Le log d'installation commence désormais par un en-tête identifiant
l'installation : date, VM, distribution + version, architecture, branche, IP.
Écrit dès la création du log (plus jamais vide au démarrage).
_qemu_install_erplibre_monitored déduit distro/version/arch de chaque VM
(nom via _qemu_infra_name + arch via virsh dumpxml) et les passe à
launch_installs, qui écrit l'en-tête et les stocke dans le manifeste.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Menu « Déployer l'infra ERPLibre » : la sélection d'architecture propose
désormais [all] = toutes les architectures supportées. L'architecture
devient une dimension à part entière de la matrice de déploiement.
- [all] archis + [all] catalogue : une VM par (distro, version, archi
publiée par cette distro). Ex. ubuntu -> amd64/arm64/s390x, debian/fedora
-> amd64/arm64, arch -> amd64 (30 VM au total avec le catalogue courant).
- [all] archis + [granulaire] : la liste à plat inclut l'archi ([amd64]/
[arm64]/[s390x]) ; on choisit des combinaisons précises par virgules.
- [all] archis + [principal] : version par défaut de chaque distro × chaque
archi supportée.
- Une archi précise (arm64/s390x) restreint le catalogue aux distros qui la
publient (inchangé).
selected porte l'archi par élément ; les noms sont suffixés par archi pour
les non-natives (erplibre-ubuntu-2604-s390x) -> pas de collision. --arch
transmis par VM. Chaque distro ne reçoit que les archis QU'ELLE publie.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Symptôme : ~/.ssh/config (et l'install) pointaient sur .31 alors que la VM
était joignable sur .32 -> SSH KO (« No route to host »), console OK.
Cause : au boot, une image cloud demande d'abord une IP DHCP avec son
hostname par défaut (« ubuntu ») -> 1er bail ; puis cloud-init fixe le vrai
hostname et le client redemande -> 2e bail (IP différente). La MÊME MAC a
donc DEUX baux ; le 1er (« ubuntu ») devient périmé. Le code retenait
aveuglément le PREMIER IPv4 de « virsh domifaddr » = le bail périmé. Plus
visible sur s390x/arm64 émulé (boot lent -> les deux baux coexistent).
Fix :
- todo._qemu_vm_ip : renvoie en priorité l'IP dont le bail dnsmasq porte le
hostname == nom de la VM (bail définitif), sinon une IP JOIGNABLE (sshd up,
test TCP:22), sinon le dernier bail — jamais le 1er au hasard. Attente
portée à 10 min (boot émulé lent). Helpers _qemu_lease_candidates /
_qemu_ip_reachable / _qemu_lease_ip_for_host.
- deploy_qemu.wait_for_ip : même logique (IP joignable, sinon la plus
récente) pour l'IP affichée en fin de déploiement standalone.
Validé sur la VM s390x réelle : candidats [.31, .32] -> choisit .32
(hostname-match + seule joignable) ; ssh via alias OK.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
1) Nommage : _qemu_infra_name ajoute un suffixe d'architecture quand elle
diffère de la native de l'hôte -> déployer un s390x sur un hôte amd64
donne « erplibre-ubuntu-2604-s390x » (au lieu de « erplibre-ubuntu-2604 »).
Évite les collisions de noms entre archis et rend l'archi visible. Passé
dans les 3 appelants (VM unique + plan + jobs de l'infra).
2) Log d'installation vide : sur une archi ÉMULÉE (s390x/arm64 sur x86) le
boot prend plusieurs minutes ; pendant ce temps l'attente n'écrivait rien
-> le log restait VIDE et paraissait « bloqué ». _launch_one écrit
désormais un en-tête d'attente immédiat + un battement toutes les ~30 s,
et l'attente sshd/cloud-init passe de ~12 à ~20 min (boot émulé lent).
_qemu_wait_ssh (chemin streamé) : timeout porté à 20 min également.
Validé : nommage (amd64/natif sans suffixe, s390x/arm64 suffixés) ; le log
se remplit dès le départ (en-tête + « ... 30s »).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Ajoute l'architecture arm64 (aarch64) au déploiement, en plus d'amd64
(x86_64) et s390x. Disponibilité réelle vérifiée (juillet 2026) :
- arm64 : Ubuntu, Debian, Fedora (Arch : pas d'image cloud aarch64 -> rejet).
- s390x : Ubuntu seulement (inchangé).
deploy_qemu.py :
- host_arch() : arch native de l'hôte ; toute arch différente est ÉMULÉE
(TCG, --virt-type qemu) — plus de liste FOREIGN_ARCHES figée.
- virt_install : arm64 -> --arch aarch64 --machine virt --boot uefi (firmware
AAVMF résolu par libvirt) ; s390x inchangé ; x86 UEFI/OVMF inchangé.
- ensure_emulator(arch) généralisé : installe qemu-system-aarch64 + firmware
UEFI AAVMF (arm64) ou qemu-system-s390x (s390x), selon le gestionnaire de
paquets, avec vérif de présence (binaire + firmware pour arm64).
- Validation --arch tôt via ARCH_DISTRO_SUPPORT (message clair si la distro
ne publie pas l'arch). Les URLs d'images arm64 marchent déjà via les alias
(fedora/arch aarch64 ; ubuntu/debian arm64).
todo.py : menus d'architecture (VM unique + infra) proposent amd64/arm64/
s390x selon la distro ; l'architecture NATIVE de l'hôte est marquée d'un *
(défaut) ; les autres sont signalées « émulé, lent ». Le catalogue infra est
restreint aux distros publiant l'arch choisie (arm64 -> ubuntu/debian/fedora,
s390x -> ubuntu).
install_debian_dependency.sh : wkhtmltopdf (deb amd64 en dur) ignoré
best-effort sur toute arch non-x86_64 (au lieu d'avorter l'install).
Validé : dry-runs Ubuntu/Debian/Fedora arm64 (bonnes URLs + virt-install
aarch64/virt/uefi/qemu), rejet Arch arm64, non-régression s390x, menus et
filtrage simulés (natif *, arm64 par distro).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Menu « Déployer l'infra ERPLibre » :
- Nouveau choix [granulaire] dans la sélection des distributions : affiche
la liste À PLAT de TOUTES les versions du catalogue (distro + version,
défauts marqués d'un *) et permet d'en choisir plusieurs par leurs numéros
séparés par des virgules (ex. « 1,3,12 »). Complète [all] et [principal].
- Demande l'ARCHITECTURE du parc en début de flux, par défaut l'architecture
NATIVE de l'hôte (amd64/arm64/s390x via uname -m). s390x est proposé mais
émulé (lent) et n'a d'images cloud que pour Ubuntu -> le catalogue est
alors restreint à Ubuntu (les autres distros sont ignorées avec un
avertissement). --arch est transmis à deploy_qemu.py quand ≠ amd64.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Après le passage à pacman, l'init PostgreSQL échouait :
« /usr/bin/postgres: /usr/lib/libm.so.6: version GLIBC_2.44 not found ».
Cause : Arch est en rolling release et NE SUPPORTE PAS les mises à jour
partielles. Sur une image cloud dont la glibc date du build de l'image, un
« pacman -S <paquet récent> » (postgresql 18.4) installe un binaire lié à
une glibc plus récente que celle du système -> symbole introuvable.
Fix : mise à jour COMPLÈTE (pacman -Syu) avant d'installer, dans les deux
endroits : install_arch_linux.sh (deps OS) et le bootstrap Arch de
_qemu_erplibre_remote_cmd (todo.py, remplace -Syy par -Syu).
Validé sur VM Arch réelle : après -Syu, « postgres (PostgreSQL) 18.4 » OK,
initdb OK, service postgresql actif, superuser erplibre créé, psql connecte.
Chaîne complète confirmée : gcc 16.1.1, make, node, psql tous présents.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Deux échecs d'install ERPLibre sur VM constatés dans les logs :
Arch — install_arch_linux.sh utilisait « yay » (helper AUR ABSENT d'une
image cloud et qui refuse de tourner en root) et n'installait JAMAIS
base-devel : sur une image cloud fraîche rien ne s'installait, donc pas de
compilateur C -> pyenv : « no acceptable C compiler found » -> build de
Python 3.12 échoué -> pas de venv -> pip/poetry/repo absents. Réécrit avec
pacman (dépôts officiels) : base-devel (gcc/make), deps de build pyenv
(openssl/zlib/xz/tk/…), PostgreSQL (+ initdb, Arch ne l'initialise pas),
Node/npm, deps Odoo en best-effort paquet par paquet (pacman refuse toute
la transaction sur un seul nom inconnu). wkhtmltopdf (AUR) : ignoré
proprement.
Fedora — « Connection closed by remote host » (exit 255) dès le début :
« cloud-init status --wait » tournait dans une session SSH UNIQUE tuée
quand cloud-init régénère les clés d'hôte et REDÉMARRE sshd au 1er boot.
On attend désormais la FIN de cloud-init via des connexions COURTES
successives (chaque tentative survit à un redémarrage de sshd), AVANT de
lancer l'install — dans les deux chemins : _qemu_wait_ssh (streamé) et
_launch_one (détaché/monitoré). On matche sur le TEXTE de « cloud-init
status » (done/disabled/error/degraded) car son code de sortie n'est pas
fiable selon la version.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Ajoute --arch s390x au déploiement QEMU. Réalité constatée (juillet 2026) :
seul Ubuntu publie des images cloud s390x (cloud-images.ubuntu.com : OK) ;
Debian et Fedora n'en publient pas (404), Arch ne cible que x86_64/aarch64.
s390x est donc scopé à Ubuntu et rejeté proprement pour les autres distros.
deploy_qemu.py :
- FOREIGN_ARCHES / S390X_DISTROS : s390x n'est valide que pour Ubuntu.
- virt_install : sur s390x -> --arch s390x, --machine s390-ccw-virtio,
--virt-type qemu (émulation TCG, pas de KVM sur hôte x86), console SCLP
(pas de série ISA), amorçage IPL/zipl (aucun --boot UEFI/BIOS). Les
disques/réseau bus=virtio sont mappés en virtio-ccw par libvirt.
- ensure_s390x_emulator : installe qemu-system-s390x au besoin
(apt: qemu-system-misc, dnf: qemu-system-s390x, pacman:
qemu-emulators-full, zypper: qemu-s390).
- Avertit que s390x est ÉMULÉ (lent) sur un hôte x86.
todo.py : le menu « Déployer une VM » demande l'architecture (s390x proposé
uniquement pour Ubuntu, avec avertissement lenteur) et passe --arch.
install_debian_dependency.sh : wkhtmltopdf n'a pas de build s390x -> skip
best-effort au lieu d'avorter l'install (la branche s390x rust-all existait
déjà pour compiler les wheels).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Fedora install stalled: the log stopped right after boot with no exit
marker. Cause: cloud-init was running "dnf -y install qemu-guest-agent
openssh-server" at first boot; on this host's slow VM network that dnf
took many minutes (metadata refresh + download), so cloud-init stayed
"running" and the install (which waits for cloud-init) never proceeded.
Fix: do NOT install any package via cloud-init. sshd is already present
in every cloud image (verified Ubuntu/Debian/Fedora/Arch) and is just
enabled via runcmd; the tools (curl/git/make…) are installed by the
ERPLibre bootstrap with optimised mirrors. cloud-init now finishes in
seconds (Fedora: "status: done" at 10s instead of blocking 5+ min).
--package still adds a cloud-init packages block on demand.
Also: when ERPLibre is installed via the infra menu, add
ERPLIBRE_EXTRA_DISK_GB (5G) to each VM's disk, because the image minimum
left only ~97 MB free after installation. Drop the now-useless
"--package git" (the bootstrap installs git).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The Arch install failed at once: "error: failed to synchronize all
databases (unable to lock database)" then "reflector: command not
found". Cause: cloud-init was still running its own pacman (installing
qemu-guest-agent/openssh) and held /var/lib/pacman/db.lck when our
bootstrap started, so every pacman call failed and reflector never got
installed.
Fix: the remote install now waits for cloud-init to finish first
("cloud-init status --wait", 15 min timeout) before touching any package
manager — this releases the apt/dnf/pacman lock cloud-init holds during
its package stage (helps all distros). For Arch, also drop a stale
db.lck when no pacman is actually running. Verified live: cloud-init
done, no lock, reflector + refresh + curl/git/make all succeed.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Dashboard: the info bar under the log now shows the selected VM's log
file path (in addition to its ssh command), so it can be opened/shared.
Install bootstrap: each package-manager branch first refreshes the repos
so the VM is as fast as possible, and Arch (pacman) is now supported:
- apt: apt-get update
- dnf: dnf makecache (dnf5 picks the fastest mirrors)
- pacman (Arch): reflector selects the 20 fastest HTTPS mirrors ->
pacman -Syy -> install curl/git/make (Arch was previously unsupported
by the bootstrap and would abort with "no package manager").
Validated live on the Arch VM: reflector + refresh + install all OK.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Arch (rolling release, single "latest" version) joins ubuntu/debian/
fedora: official cloud image geo.mirror.pkgbuild.com/images/latest/
Arch-Linux-x86_64-cloudimg.qcow2 (cloud-init included), osinfo=archlinux
(known locally), UEFI boot + virtio seed like the others. ERPLibre
already has install_arch_linux.sh. Exposed in the infra/deploy menus.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
From the QEMU install logs: Debian 12 succeeded, Ubuntu 24.04 and
Fedora 42 failed.
Ubuntu (install_debian_dependency.sh):
- apt failed with "Could not get lock" (cloud-init/unattended-upgrades
hold it on first boot) -> all apt-get calls now use
DPkg::Lock::Timeout=600 so apt waits for the lock.
- "postgis" is not a package on Ubuntu 24.04, so the postgresql line
exited 1 before installing build-essential -> no C compiler -> pyenv
could not build Python 3.12.10. PostGIS is now best-effort (tries
postgis, then postgresql-postgis) and never aborts; postgresql-contrib
is added.
Fedora (new install_fedora_dependency.sh, wired into install_dev.sh):
- install_dev.sh dispatched Fedora to the apt script; it now has a
fedora / ID_LIKE branch calling a dnf-based dependency installer
(dev tools, postgresql-server + initdb, pyenv build deps, node, etc.),
using --refresh --skip-unavailable to tolerate mirror/name issues.
Bootstrap (todo.py): the dnf "curl git make" install hit a GPG/checksum
failure on a fresh image; it now uses --refresh and retries after
"dnf clean all".
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
After "Opening the interactive monitor..." the install now lists every
VM's log file path, so they can be read or shared even when leaving the
dashboard before the installs finish.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
