LongTest était le SEUL répertoire en CamelCase que nous ayons créé. Les deux
exceptions sous script/ — OCA_maintainer-tools, OCA_odoo-module-migrator —
sont des noms de dépôts amont tirés par Google Repo, pas les nôtres. Tout le
reste est en minuscules avec des soulignés : image_db, code_generator,
fork_github_repo, shell_script_odoo.
Le nom avait été repris tel qu'il m'avait été dicté, sans être confronté à la
convention — le contrôle même que le reste de ce travail applique partout.
50 occurrences dans 8 fichiers. Le menu TODO résout le nouveau chemin, l'essai
à blanc passe, et les 125 tests des trois fichiers touchés restent verts.
--- EN ---
LongTest was the ONLY CamelCase directory we created. The two exceptions under
script/ — OCA_maintainer-tools, OCA_odoo-module-migrator — are upstream repo
names pulled by Google Repo, not ours. Everything else is lowercase with
underscores: image_db, code_generator, fork_github_repo, shell_script_odoo.
The name had been taken as dictated, without being checked against the
convention — the very check the rest of this work applies everywhere.
50 occurrences across 8 files. The TODO menu resolves the new path, the dry run
passes, and the 125 tests in the three touched files stay green.
Assisted-by: claude-opus-5
(cherry picked from commit 170ee61e50dfeff638c84c07eadac00c62526e4d)
Le défaut promettait dix étages qu'aucune machine ne tient. Une descente
complète par ligne, sur 28 cœurs :
étage 1 : 0 s d'amorçage, 200 s d'installation, 280 s en tout
étage 2 : 37 s, 344 s, 495 s
étage 3 : 93 s, 777 s, 1 064 s
étage 4 : 15 608 s, 26 306 s, n'a pas abouti
Trois étages coûtent une demi-heure. Le quatrième a coûté 4 h 20 d'amorçage et
7 h 18 d'installation sur la même machine : tout y est 15 à 30 fois plus lent,
pas une seule étape. C'est aussi là que les fabricants s'arrêtent — le
quatrième étage est le troisième hyperviseur imbriqué, AMD en documente deux.
La profondeur reste le seul paramètre, et le README dit désormais ce qu'on
achète en la montant.
--- EN ---
The default promised ten levels no machine can hold. One full descent per row,
on 28 cores:
level 1: 0 s boot, 200 s install, 280 s total
level 2: 37 s, 344 s, 495 s
level 3: 93 s, 777 s, 1 064 s
level 4: 15 608 s, 26 306 s, did not finish
Three levels cost half an hour. The fourth cost 4 h 20 of boot and 7 h 18 of
install on the same machine: everything there is 15 to 30 times slower, not one
step. It is also where the vendors stop — level 4 is the third nested
hypervisor, and AMD documents two.
Depth remains the only parameter, and the README now says what raising it buys.
Assisted-by: claude-opus-5
(cherry picked from commit 226d6ffa3c664ba9e1a6dfdf48d52027b52eda23)
Ma propre conclusion de ce matin était fausse, et une mesure l'a réfutée.
J'avais écrit — code, README, commit — que le gel à 12 vCPU venait du
SURENGAGEMENT : cette VM avait douze vCPU sur un hôte qui en avait deux.
Descente réelle : l'étage 4 à huit vCPU, sur un parent qui en avait NEUF,
charge 1,47, aucun surengagement. Gelé pareil. 32 Mio lus en 106 minutes, même
RIP à trois relevés espacés de cinq minutes. C'est le nombre de vCPU de
l'invité imbriqué, et rien d'autre.
Le dimensionnement de bas en haut donnait 8 vCPU à l'étage 4, 7 au 5 : il
rendait larges précisément les étages qui doivent rester étroits. Trois
largeurs fixes le remplacent — métal, intermédiaire, fond. La mémoire et le
disque, eux, restent dimensionnés depuis le bas.
VCPU_INTERMEDIAIRE = 3 est une hypothèse assumée : deux démarre au quatrième
étage, huit gèle, rien n'est mesuré entre les deux.
--- EN ---
My own conclusion from this morning was wrong, and a measurement refuted it. I
had written — code, README, commit — that the 12-vCPU freeze came from
OVERCOMMIT: that VM had twelve vCPU on a host with two.
Real descent: level 4 at eight vCPU, on a parent with NINE, load 1.47, no
overcommit whatsoever. Frozen all the same. 32 MiB read in 106 minutes, same
RIP at three readings five minutes apart. It is the nested guest's vCPU count,
nothing else.
Bottom-up sizing gave level 4 eight vCPU and level 5 seven: it made wide
exactly the levels that must stay narrow. Three fixed widths replace it —
metal, intermediate, floor. Memory and disk stay sized from the bottom.
VCPU_INTERMEDIAIRE = 3 is an owned hypothesis: two boots at the fourth level,
eight freezes, nothing is measured in between.
Assisted-by: claude-opus-5
(cherry picked from commit ee45ff4f333c69e3862e277334cb34efa39bbd57)
Le plan cédait à l'enfant ce que le parent pouvait céder. Descente réelle à
dix étages : l'étage 4 a reçu 44 Go et 2 vCPU sur un hôte qui en avait 2 —
cent pour cent de surengagement, à chaque étage. Son installation dure 2 h 52
et n'est pas finie, contre 793 s pour l'étage 3. Extrapolé, le dixième
demandait des années.
Le plus profond reçoit désormais ce qu'un Proxmox de test demande, et chaque
parent ajoute son seul surcoût : un vCPU, 2 Gio, 10 Go. Dix étages tiennent
sur 11 vCPU et 22 Go au premier, contre 50 Go avant.
Corrige aussi l'explication du gel à 12 vCPU : cette VM avait douze vCPU sur
un hôte qui en avait deux. C'est le surengagement qui gèle, pas le douze.
--- EN ---
The plan handed the child whatever the parent could spare. Real ten-level
descent: level 4 got 44 GB and 2 vCPU on a host that had 2 — a hundred
percent overcommit, at every level. Its install has run 2h52 and is not done,
against 793 s for level 3. Extrapolated, the tenth wanted years.
The deepest level now gets what a test Proxmox asks for, and each parent adds
its own overhead only: one vCPU, 2 GiB, 10 GB. Ten levels fit in 11 vCPU and
22 GB at the first, against 50 GB before.
Also corrects the account of the 12-vCPU freeze: that VM had twelve vCPU on a
host with two. Overcommit freezes, not the twelve.
Assisted-by: claude-opus-5
(cherry picked from commit 7cda84bf391ee3ed36c5953ca4b86df44bd09e3b)
La doc et l'en-tête de l'algorithme affirmaient qu'au quatrième étage le noyau
invité gelait « au même octet quelles que soient les ressources ». Lancer la
descente l'a réfuté : son propre quatrième étage, à 2 vCPU, a démarré, s'est
installé, et a écrit des gigaoctets. La VM examinée à la main en avait douze.
Ce n'était donc pas un plafond d'imbrication mais un plafond de PARALLÉLISME
sous imbrication — précisément ce que l'algorithme borne, et qui cesse ainsi
d'être une supposition.
Le « même octet », par ailleurs, ne voulait rien dire de ce qu'on lui faisait
dire : 33 682 432 octets, c'est 32 Mio, la taille des fichiers d'amorçage.
Retirer de la mémoire ne le déplaçait pas parce qu'il ne dépendait pas de la
mémoire, pas parce qu'un mur absolu s'y trouvait. La conclusion — ne pas
borner la RAM — reste juste ; sa justification était fausse.
Une affirmation fausse dans la documentation est pire que pas de
documentation : elle décide à la place du lecteur. Les deux passages disent
maintenant ce qui a été mesuré, sur quoi, et ce que la descente a montré
ensuite.
--- EN ---
The documentation and the algorithm's header claimed that at the fourth level
the guest kernel froze "at the same byte whatever the resources". Running the
descent refuted it: its own fourth level, at 2 vCPU, booted, installed, and
wrote gigabytes. The VM examined by hand had twelve.
So it was not a nesting ceiling but a PARALLELISM ceiling under nesting —
exactly what the algorithm caps, which thereby stops being a guess.
The "same byte", moreover, did not mean what it was made to mean: 33,682,432
bytes is 32 MiB, the size of the boot files. Removing memory did not move it
because it did not depend on memory, not because an absolute wall sat there.
The conclusion — do not cap RAM — still holds; its justification was wrong.
A false claim in documentation is worse than no documentation: it decides in
the reader's place. Both passages now say what was measured, on what, and what
the descent showed afterwards.
Assisted-by: Claude Opus 5
(cherry picked from commit b8c53eaf104f6891703e71b540c76ffd5994a2cb)
La profondeur d'imbrication praticable ne se déduit pas, elle se mesure. Une
mesure à la main a trouvé, au quatrième étage, un invité 36 fois plus lent que
le temps réel — 583 secondes d'horloge pour 16 secondes de temps invité,
chaque ligne d'ACPI prenant une seconde — puis un noyau gelé au MÊME octet
quelles que soient les ressources. Un chiffre obtenu une fois, sur une
machine, n'est pas un chiffre.
D'où trois choses.
L'algorithme, en fonctions pures. Deux ressources s'épuisent en descendant :
la mémoire, chaque étage gardant de quoi faire tourner ses propres démons, et
le disque, celui de l'enfant vivant DANS celui du parent. Une troisième se
dégrade, et elle borne le vCPU à deux au-delà du premier étage : douze ont
gelé le noyau invité, les mêmes deux avançaient. La mémoire n'est PAS bornée —
la même VM gelait au même octet avec 9 Go et avec 2 Go, donc la rogner ne
gagnerait rien et priverait l'étage du dessous. Le plan est annoncé avant
toute création, et jamais au-delà de ce qui tient.
Le garde-fou dans l'écran. Il lisait la capacité de l'HÔTE et l'offrait en
entier : sur un troisième étage à 14 cœurs, il a proposé 12 vCPU à une VM qui
n'a jamais démarré. Le nombre n'était pas absurde pour la machine ; il l'était
pour sa profondeur, que l'écran ignorait. Elle se compte maintenant sur la
chaîne de ProxyJump — un rebond par étage, et c'est nous qui écrivons ces
entrées.
Le test long, dans LongTest/ et non dans test/ : le lanceur unitaire doit
rester lançable en quelques secondes, partout, y compris sans virtualisation.
La descente est uniforme — créer, attendre le ssh, installer, redémarrer et
vérifier le noyau, remettre pmxcfs debout, contrôler le stockage — et s'arrête
au premier étage qui échoue en NOMMANT l'étape. Il envoie notre
install_proxmox.sh par scp plutôt que de laisser la VM cloner le dépôt : c'est
notre code qu'on éprouve, et un correctif absent du distant a fait revenir le
même défaut sur trois VM.
--- EN ---
The practicable nesting depth cannot be deduced, only measured. A manual
measurement found, at the fourth level, a guest 36 times slower than real time
— 583 seconds of wall clock for 16 seconds of guest time, each ACPI line
taking a second — then a kernel frozen at the SAME byte whatever the
resources. A number obtained once, on one machine, is not a number.
Hence three things.
The algorithm, in pure functions. Two resources run out going down: memory,
each level keeping what its own daemons need, and disk, the child's living
INSIDE the parent's. A third degrades, and it caps the vCPU at two beyond the
first level: twelve froze the guest kernel, the same two progressed. Memory is
NOT capped — the same VM froze at the same byte with 9 GB and with 2 GB, so
trimming it would gain nothing and starve the level below. The plan is
announced before anything is created, and never beyond what fits.
The guard in the screen. It read the HOST's capacity and offered all of it: on
a third level with 14 cores it proposed 12 vCPU to a VM that never booted. The
number was not absurd for the machine; it was for its depth, which the screen
did not know. It is now counted on the ProxyJump chain — one hop per level,
and we are the ones writing those entries.
The long test, in LongTest/ and not test/: the unit runner must stay runnable
in seconds, anywhere, including without virtualisation. The descent is uniform
— create, wait for ssh, install, reboot and check the kernel, bring pmxcfs
back, check the storage — and stops at the first level that fails, NAMING the
step. It sends our install_proxmox.sh over scp instead of letting the VM clone
the repository: it is our code being exercised, and a fix absent from the
remote made the same defect return on three VMs.
Assisted-by: Claude Opus 5
(cherry picked from commit 4f70c461330cac6f46783a60e0f33052a979fa23)
