erplibre/script/proxmox
Mathieu Benoit 98c2355ca0 [FIX] suivi : relevé Proxmox squelettique, index par nom, état terminal
Une cause, deux symptômes. « /cluster/resources » est bâti par pvestatd ;
celui-ci arrêté, l'hôte rend quand même une entrée par VM, mais
SQUELETTIQUE — ni nom, ni mémoire, ni disque, et « status: unknown ». Le
relevé était indexé par NOM : l'entrée disparaissait donc, la VM passait pour
absente alors que l'hôte venait de la nommer, et trois tours plus tard 🗑.
Comme « effacée » est un état TERMINAL, la ligne comptait pour finie — d'où
« 1/1 terminées · 00:09 » sur une installation qui tournait.

Le relevé est maintenant indexé par VMID, seul identifiant unique d'un hôte
Proxmox, et la correspondance vers les noms se fait là où le manifeste est
sous les yeux. Une entrée squelettique reste donc une VM présente, avec ce que
l'hôte sait d'elle — sa taille occupée, que « du » donne par VMID.

Reste à savoir pourquoi pvestatd était mort. Son journal le dit mot pour mot :
« ipcc_send_rec failed: Connection refused » — pve-cluster absent, c'est-à-dire
la panne /etc/hosts d'hier. Tous les services de Proxmox avaient échoué
ensemble, et systemd n'y revient jamais seul. L'installation relançait le seul
pve-cluster ; elle relance désormais l'ensemble, pve-cluster d'abord puisqu'il
monte /etc/pve.

Vérifié sur l'hôte : pvestatd relancé, et les colonnes passent de « - - - » à
« 3.4G/4.0G, 2.3G/25G, 2.2G écrit ».

--- EN ---

One cause, two symptoms. "/cluster/resources" is built by pvestatd; with it
stopped the host still returns one entry per VM, but SKELETAL — no name, no
memory, no disk, and "status: unknown". Readings were indexed by NAME, so that
entry vanished, the VM looked absent although the host had just named it, and
three rounds later 🗑. Since "deleted" is a TERMINAL state the row counted as
finished — hence "1/1 done · 00:09" on a running install.

Readings are now indexed by VMID, a Proxmox host's only unique identifier, and
the mapping to names happens where the manifest is at hand. A skeletal entry
therefore stays a present VM, with whatever the host does know about it — its
used size, which "du" reports per VMID.

Why was pvestatd dead? Its journal says it verbatim: "ipcc_send_rec failed:
Connection refused" — no pve-cluster, that is yesterday's /etc/hosts fault. All
of Proxmox's services had failed together, and systemd never returns to them on
its own. The installer restarted pve-cluster alone; it now restarts the whole
set, pve-cluster first since it mounts /etc/pve.

Verified on the host: pvestatd restarted, and the columns go from "- - -" to
"3.4G/4.0G, 2.3G/25G, 2.2G written".

Assisted-by: Claude Opus 5
(cherry picked from commit 3fb85f66842d4b0e9d6ae6446691229b31ef725a)
2026-08-29 01:53:02 -04:00
..
install_proxmox.sh [FIX] suivi : relevé Proxmox squelettique, index par nom, état terminal 2026-08-29 01:53:02 -04:00
proxmox_deploy.py [FIX] proxmox : pmxcfs sans adresse routable, et le stockage vide 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

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:

  1. From the local QEMU VMs — a proxmox VM deployed here. Its address comes from the DHCP lease, nothing to retype.
  2. By address — user@host, plus an optional SSH jump.
  3. 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.