Amorçage du quatrième étage, mesuré sur deux descentes complètes : 1 664 s à 2 vCPU, 15 608 s à 3. Un seul vCPU de plus, ×9,4. Aux étages 2 et 3 le même vCPU ne coûte RIEN — ssh en 37 s et 93 s, comme à deux. Le « gel » observé à 8 et 12 vCPU n'est probablement pas autre chose que cette courbe poussée assez loin : 1 664 × 9,4 par vCPU dépasse vite toute patience, et un RIP immobile à cinq minutes d'intervalle ne s'en distingue pas. D'où un SEUIL de profondeur au lieu d'une largeur uniforme. Le troisième vCPU reste aux étages 2 et 3, où il est gratuit et où il enlève le surengagement qui affamait l'installation de l'étage 4 — celle-ci ne finissait pas avec un parent à 2 vCPU, elle progresse avec un parent à 3. À partir du quatrième étage, le strict minimum. La combinaison ainsi obtenue — parent 3, enfant 2 — n'a jamais été mesurée : les deux essais étaient (2, 2) et (3, 3). --- EN --- Fourth-level boot, measured on two full descents: 1,664 s at 2 vCPU, 15,608 s at 3. One more vCPU, ×9.4. At levels 2 and 3 that same vCPU costs NOTHING — ssh in 37 s and 93 s, same as at two. The "freeze" seen at 8 and 12 vCPU is most likely nothing but this curve taken far enough: 1,664 × 9.4 per vCPU quickly exceeds any patience, and a static RIP five minutes apart is indistinguishable from it. Hence a depth THRESHOLD instead of a uniform width. The third vCPU stays at levels 2 and 3, where it is free and where it removes the overcommit that starved level 4's install — which never finished with a 2-vCPU parent and does progress with a 3-vCPU one. From the fourth level down, the strict minimum. The resulting combination — parent 3, child 2 — has never been measured: the two attempts were (2, 2) and (3, 3). Assisted-by: claude-opus-5 (cherry picked from commit 9a5583a4b9461a087d161775764c560c82e0609e) |
||
|---|---|---|
| .. | ||
| install_proxmox.sh | ||
| nesting.py | ||
| proxmox_deploy.py | ||
| README.base.md | ||
| README.fr.md | ||
| README.md | ||
Deploying VMs on a Proxmox VE host
Two different things live in this directory:
install_proxmox.shturns a Debian into a Proxmox hypervisor. Seescript/qemu/README.md, which documents theproxmoxdistro of the deployment catalog.proxmox_deploy.pydeploys VMs on such a host, fromTODO › Execute › Deploy › Proxmox VE, right underQEMU/KVM.
The whole difference: the hypervisor is elsewhere
With QEMU/KVM, the hypervisor is the machine running the script. With Proxmox it is somewhere else, so the first question is which host — and the answer is remembered for the session. Three ways, all offered by the menu:
- From the local QEMU VMs — a
proxmoxVM deployed here. Its address comes from the DHCP lease, nothing to retype. - By address —
user@host, plus an optional SSH jump. - From
~/.ssh/config— the alias already carries user, port and ProxyJump; nothing else is asked.
The chosen host is then checked, not assumed: pveversion proves it is a
Proxmox, id -u and sudo -n true decide whether commands need sudo, and an
unknown SSH host key is offered for recording (with ssh-keyscan, never by
disabling the check — a hypervisor is not a throwaway VM).
# Ce que l'outil envoie, et qu'on peut rejouer à la main :
ssh erplibre@pve1 sudo sh -c 'qm list'
ssh erplibre@pve1 sudo sh -c 'pvesm status --content images'
Why SSH and qm, not the REST API
The API needs a token or a ticket to create and renew. qm is the path every
Proxmox administrator knows, the repository already manages SSH access
(~/.ssh/config, ProxyJump, keys), and the commands stay readable in the log —
so they can be replayed by hand. That is how every failure of this module was
diagnosed.
sudo sh -c '<whole command>' and not sudo <command>: these commands are
sequences and redirections. Prefixing with sudo would elevate only the first
word, and the redirection would still be the unprivileged shell's.
Four traps met on a real host
A Proxmox installed on Debian has no vmbr0 — the ISO installer creates
one, that procedure does not. And qm create requires a bridge.
The menu offers an internal bridge (vmbr0, 10.10.10.1/24, NAT through
the uplink). Never adding the physical NIC to a bridge is deliberate: that
moves the host address and cuts the SSH session in progress — remotely, there
is no way back. A LAN-facing bridge is printed as a stanza to apply from a
console.
On an internal bridge no DHCP answers, so the address is static, derived from the VMID — and therefore known before the VM boots. Looking for it afterwards was absurd.
The Debian cloud image does not ship qemu-guest-agent, so Proxmox cannot tell
the address of a DHCP guest: it does not hand out the leases. The fallback is
the host's own neighbour table (ip neigh), which needs nothing from the guest.
The menu, entry by entry
The seventeen QEMU/KVM entries have their counterpart. Four of them are the
same code, because it is the same work: reopening the install monitoring,
the remote desktop tunnel, the Android emulator and the image catalog. They
reach Proxmox guests through the ~/.ssh/config entries that entry 13 writes,
with the Proxmox host as ProxyJump.
[1] Déployer une VM [8] Redimensionner un disque [15] Émulateur Android *
[2] Prévisualiser [9] Effacer des VM [16] Catalogue d'images *
[3] Télécharger une image [10] Nettoyer (orphelins) [17] Exemple (dry-run)
[4] Rouvrir le suivi * [11] Tester une VM (Odoo) [18] Changer d'hôte
[5] Lister (qm list) [12] Statistiques
[6] Adresse IP d'une VM [13] Configuration SSH
[7] Console d'une VM [14] Tunnel bureau distant *
* code partagé avec le menu QEMU/KVM
Verified
Deploying a VM inside a Proxmox that itself runs in a libvirt VM: image
downloaded on the host, internal bridge created, static address, cloud-init
user and key, disk resized, qm start. Then ssh vm-essai from the outside
reaches it through the jump — three nested levels. Resize 12G → 16G, delete
with --purge, orphan scan: all checked against Proxmox VE 9.2.11.