History

Mathieu Benoit 7dc5df67c3 [FIX] proxmox : le pont interne prenait l'adresse de sa propre passerelle Un Proxmox dans un Proxmox hérite du réseau interne de son parent : la VM vivait en 10.10.10.152, passerelle 10.10.10.1. Le pont interne, lui, avait son adresse CODÉE EN DUR à 10.10.10.1/24. Lui demander de la poser sur son propre pont, c'est prendre l'adresse de sa passerelle et rendre tout le /24 local. La machine s'isole au milieu de la commande qui la configure : « ifup » n'a jamais rendu la main, la VM ne répondait plus ni en ssh ni en ping. Le réseau est donc CHOISI, d'après ce que l'hôte connaît déjà — ses adresses et ses routes, car une route sans adresse locale suffit à créer le conflit, et la route par défaut en est l'exemple exact. Le chevauchement se calcule sur les réseaux et non sur les trois premiers octets : « 10.0.0.0/8 » écarte alors bien tous les candidats en 10.x. Plus aucun libre ? On le dit, plutôt que d'en écraser un — écraser, ici, c'est couper la seule voie d'accès. Le repli « ifreload -a » s'en va aussi. Il rechargeait TOUTES les interfaces, y compris celle qui porte la session, et sur une image cloud l'interface principale est décrite ailleurs — ifupdown2 la descend sans la remonter. Le repli monte maintenant le pont à la main, sans toucher à rien d'autre ; la strophe le rend persistant. La règle de masquerading se teste avant de s'ajouter, donc une reprise n'empile rien. Le test d'origine interdisait « 2>/dev/null » sur toute la ligne pour que l'erreur d'ifup reste lisible. L'intention est gardée, portée sur l'appel à ifup seul : le repli, lui, sonde légitimement. --- EN --- Proxmox inside Proxmox inherits its parent's internal network: the VM lived at 10.10.10.152, gateway 10.10.10.1. The internal bridge had its address HARDCODED to 10.10.10.1/24. Asking it to put that on its own bridge takes its gateway's address and makes the whole /24 local. The machine isolates itself in the middle of the command configuring it: "ifup" never returned, the VM answered neither ssh nor ping. The subnet is now CHOSEN from what the host already knows — its addresses and its routes, since a route with no local address is enough to collide, and the default route is exactly that case. Overlap is computed on networks rather than on the first three octets, so "10.0.0.0/8" correctly rules out every 10.x candidate. None left? We say so rather than overwrite one — overwriting here means cutting the only way in. The "ifreload -a" fallback goes too. It reloaded ALL interfaces, including the one carrying the session, and on a cloud image the main interface is described elsewhere — ifupdown2 takes it down without bringing it back. The fallback now raises the bridge by hand, touching nothing else; the stanza makes it persistent. The masquerade rule is checked before being added, so a retry piles nothing up. The original test banned "2>/dev/null" across the whole line so ifup's error stayed readable. That intent is kept, narrowed to the ifup call itself: the fallback legitimately probes. Assisted-by: Claude Opus 5 (cherry picked from commit 57991b186cf891b0db6b7228fb626c4c1af317cd)		2026-08-29 01:53:02 -04:00
..
install_proxmox.sh	[ADD] proxmox : déployer des VM sur un hôte Proxmox distant	2026-08-23 05:54:38 -04:00
proxmox_deploy.py	[FIX] proxmox : le pont interne prenait l'adresse de sa propre passerelle	2026-08-29 01:53:02 -04:00
README.base.md	[ADD] proxmox : déployer des VM sur un hôte Proxmox distant	2026-08-23 05:54:38 -04:00
README.fr.md	[ADD] proxmox : déployer des VM sur un hôte Proxmox distant	2026-08-23 05:54:38 -04:00
README.md	[ADD] proxmox : déployer des VM sur un hôte Proxmox distant	2026-08-23 05:54:38 -04:00

README.md

Deploying VMs on a Proxmox VE host

Two different things live in this directory:

install_proxmox.sh turns a Debian into a Proxmox hypervisor. See script/qemu/README.md, which documents the proxmox distro of the deployment catalog.
proxmox_deploy.py deploys VMs on such a host, from TODO › Execute › Deploy › Proxmox VE, right under QEMU/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 proxmox VM 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 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.

README.md Unescape Escape