History

Mathieu Benoit 8ff88f03d2 [ADD] long_test : deep_qemu, et la preuve que KVM est bien là Le pendant de deep_proxmox : des QEMU dans des QEMU. Le ralentissement du quatrième étage vient du PROCESSEUR, mais le coût par étage vient de ce qu'on installe — un nœud Proxmox pose un noyau, corosync, ceph et une interface web là où un hôte libvirt pose libvirtd. Les deux mesures ensemble séparent ce qui tient au matériel de ce qui tient à la pile. Ce test ne peut pas se contenter de descendre. deploy_qemu.py ne passe jamais « --cpu host-passthrough » et, quand /dev/kvm manque, il n'échoue PAS : il pose « --virt-type qemu », avertit sur une ligne et crée une VM entièrement ÉMULÉE — sept minutes et demie de démarrage, aucun code de retour pour le dire. Sans garde, la descente mesurerait de la TCG empilée en croyant mesurer de l'imbrication, et rendrait un chiffre plus flatteur et faux. Chaque étage doit donc PROUVER : /dev/kvm lisible, « nested » à Y, et le domaine de l'enfant en type='kvm'. Ce qui n'a pas été lu vaut NON — un /sys/module absent, c'est un module non chargé, pas une permission. nesting_plan reçoit ses coûts : les constantes vCPU décrivent la physique de l'imbrication et valent pour les deux piles, les six nombres qui chiffrent un Proxmox non. Un étage QEMU demande 2 Go et 20 Go, contre 4 et 25. 26 tests, six garde-fous morts sous mutation. --- EN --- The counterpart to deep_proxmox: QEMU inside QEMU. The fourth level's slowdown comes from the PROCESSOR, but the per-level cost comes from what you install — a Proxmox node lays down a kernel, corosync, ceph and a web UI where a libvirt host lays down libvirtd. Together the two measurements separate what is due to the hardware from what is due to the stack. This test cannot merely descend. deploy_qemu.py never passes "--cpu host-passthrough" and, when /dev/kvm is missing, it does NOT fail: it sets "--virt-type qemu", warns on one line and creates a fully EMULATED VM — seven and a half minutes to boot, no exit code to say so. Unguarded, the descent would measure stacked TCG while believing it measured nesting, and return a more flattering, false number. Every level must therefore PROVE: /dev/kvm readable, "nested" at Y, and the child's domain type='kvm'. What was not read counts as NO — an absent /sys/module means an unloaded module, not a permission problem. nesting_plan takes its costs: the vCPU constants describe the physics of nesting and hold for both stacks, the six numbers that price a Proxmox do not. A QEMU level asks 2 GB and 20 GB against 4 and 25. 26 tests, six guards die under mutation. Assisted-by: claude-opus-5 (cherry picked from commit 39682cb1ce9648db91261387cae88c40c2a67837)		2026-08-29 01:53:03 -04:00
..
install_proxmox.sh	[FIX] proxmox : apt-daily tient le verrou au démarrage	2026-08-29 01:53:03 -04:00
nesting.py	[ADD] long_test : deep_qemu, et la preuve que KVM est bien là	2026-08-29 01:53:03 -04:00
proxmox_deploy.py	[ADD] proxmox : l'écran remet pmxcfs debout lui-même	2026-08-29 01:53:03 -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