Skip to content

Instantly share code, notes, and snippets.

@nkaurelien
Created May 5, 2026 00:31
Show Gist options
  • Select an option

  • Save nkaurelien/a9617fb731f47ee7be768329f0df4734 to your computer and use it in GitHub Desktop.

Select an option

Save nkaurelien/a9617fb731f47ee7be768329f0df4734 to your computer and use it in GitHub Desktop.
Cloner un template Proxmox via CLI (qm clone) et installer Coolify sur Debian 12 — procédure + troubleshooting

Cloner un template Proxmox via CLI et installer Coolify (Debian 12)

Procédure pour créer rapidement une nouvelle VM Proxmox à partir d'un template Debian existant, l'ajuster (RAM/CPU/disque), la démarrer, retrouver son IP DHCP, puis y installer Coolify. Tout en SSH, sans passer par la GUI Proxmox.

Prérequis

  • Un template déjà préparé dans Proxmox (VM marquée template: 1 dans qm config). Typiquement une image OSBoxes Debian 12 convertie en template.
  • Un accès SSH root à l'hôte Proxmox.
  • Le subnet de la VM en DHCP (sinon adapter avec une IP statique cloud-init ou config manuelle).

1. Repérer le template source

ssh root@PROXMOX_HOST 'qm list'
# repérer une ligne avec status "stopped" + un nom évocateur (debian12, ubuntu-cloud, ...)

ssh root@PROXMOX_HOST 'qm config 230'
# vérifier la présence de "template: 1"
# noter le storage et le disque (ex: scsi0: local-lvm:base-230-disk-0,...)

base-230-disk-0 (préfixe base-) confirme que c'est bien un volume template LVM-thin, prêt pour le linked clone.

2. Cloner, paramétrer, démarrer

# Choisir un VMID libre (ici 103)
NEW_VMID=103
TEMPLATE=230
NAME=coolify
RAM_MB=6144            # 6 Go
CORES=2

ssh root@PROXMOX_HOST "
  qm clone $TEMPLATE $NEW_VMID --name $NAME &&
  qm set $NEW_VMID --memory $RAM_MB --cores $CORES &&
  qm start $NEW_VMID &&
  qm config $NEW_VMID
"

Notes :

  • Sur un template stocké en local-lvm (LVM-thin), qm clone fait par défaut un linked clone : quasi-instantané, ne consomme que les blocs modifiés. Pour un full clone indépendant, ajouter --full 1.
  • Proxmox affiche un avertissement "Sum of all thin volume sizes exceeds the size of thin pool" — c'est un over-provisioning normal, pas une erreur, tant qu'on surveille l'usage réel du pool (pvesm status ou lvs côté pool pve/data).
  • Récupérer la MAC dans la sortie de qm config (ligne net0: virtio=BC:24:11:..,bridge=vmbr0) — utile pour l'étape suivante.

3. Trouver l'IP DHCP de la nouvelle VM

Trois méthodes possibles, par ordre de préférence.

a) Via qemu-guest-agent (le plus propre)

Si l'agent est installé et activé sur le template (agent: 1 dans qm config) :

ssh root@PROXMOX_HOST "qm guest cmd $NEW_VMID network-get-interfaces" \
  | jq -r '.[] | select(.name != "lo") | .["ip-addresses"][]? | select(.["ip-address-type"]=="ipv4") | .["ip-address"]'

b) Via la table ARP du Proxmox (sans agent)

Forcer la population de l'ARP avec un ping-sweep sur le subnet, puis grep de la MAC :

MAC="BC:24:11:1C:E3:4D"     # à reprendre depuis qm config $NEW_VMID
SUBNET="192.168.0"

ssh root@PROXMOX_HOST "
  until arp -an | grep -qi '$MAC'; do
    for i in \$(seq 1 254); do
      ping -c1 -W1 $SUBNET.\$i >/dev/null 2>&1 &
    done
    wait
    sleep 3
  done
  arp -an | grep -i '$MAC'
"

c) Via les leases DHCP du routeur

Si le routeur est accessible (Unifi, OPNsense, dnsmasq...), regarder ses leases. Méthode la plus fiable mais dépend de l'infra.

4. SSH initial

Le template OSBoxes Debian 12 conserve souvent les credentials par défaut :

User Password
osboxes osboxes.org
root osboxes.org
ssh debian@VM_IP        # si l'utilisateur "debian" existe avec une clé pré-injectée
# sinon
ssh osboxes@VM_IP       # password: osboxes.org

Bonnes pratiques immédiates après premier login :

sudo passwd osboxes                       # changer le mot de passe par défaut
sudo hostnamectl set-hostname coolify
mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAA... your_key" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
sudo apt update && sudo apt -y full-upgrade

5. Installer Coolify

Une fois loggé dans la VM :

curl -fsSL https://cdn.coollabs.io/coolify/install.sh | sudo bash

Ce script :

  • installe Docker + Compose plugin si absent,
  • crée /data/coolify/ avec config + secrets,
  • pull les images Coolify et démarre la stack via Docker Compose,
  • expose l'UI sur le port 8000 (HTTP) et 6001 (websocket realtime).

Accès UI : http://VM_IP:8000 puis création du compte admin (premier visiteur).

Recommandations Coolify

  • Min recommandé : 2 CPU, 2 Go RAM, 30 Go disque. Le clone à 6 Go / 250 G est confortable pour héberger une vingtaine de petits services.
  • Ouvrir au moins ports 22, 80, 443, 8000 sur le firewall Proxmox/cloud.
  • Pour exposer Coolify lui-même en HTTPS derrière un nom de domaine, utiliser le proxy intégré (Traefik) — config via l'UI.

Troubleshooting

qm clone: "VM is locked (clone)"

Une opération est déjà en cours sur la VM source ou destination. Attendre, ou si bloqué :

qm unlock $NEW_VMID

Le clone démarre mais reste invisible sur le réseau

  • VM démarrée mais pas de DHCP : vérifier qm config $NEW_VMID | grep net0 → bon bridge ?
  • Le bridge vmbr0 est-il connecté à un réseau qui DHCP ?
  • Console série pour voir le boot : qm terminal $NEW_VMID (depuis l'hôte Proxmox).

L'agent qm guest cmd répond QEMU guest agent is not running

L'agent n'est pas installé/activé dans le template. Soit :

  • l'installer post-clone : sudo apt install qemu-guest-agent && sudo systemctl enable --now qemu-guest-agent, puis dans la config Proxmox : qm set $NEW_VMID --agent 1, redémarrer la VM.
  • ou rester sur la méthode ARP/DHCP leases.

MAC du clone identique au template

qm clone régénère automatiquement une nouvelle MAC. Si ce n'est pas le cas (Proxmox très ancien), forcer manuellement :

qm set $NEW_VMID --net0 virtio,bridge=vmbr0,firewall=1
# (Proxmox génère une nouvelle MAC quand on omet le champ macaddr=...)

Le linked clone refuse: "storage doesn't support linked clone"

Le storage du template ne permet pas les linked clones (ex: dir, nfs non thin-provisionné). Forcer le full clone :

qm clone $TEMPLATE $NEW_VMID --name $NAME --full 1

Coolify install échoue avec "apply layer error: failed to prepare extraction snapshot"

Ce n'est généralement pas une erreur fatale : c'est une boucle de retry pendant que Docker pull des images volumineuses. Le script enchaîne overall progress: 0 out of 1 tasks pendant plusieurs minutes puis aboutit à Congratulations, ... is installed!. Patience — laisser tourner 10-15 min avant de conclure à un échec.

Si vraiment bloqué après 20+ min, voir la doc d'extension de /var (les pulls Docker remplissent /var/lib/docker, et un /var à 9 Go saturé fait échouer les extractions).

/var se remplit après quelques jours

Symptôme classique sur image OSBoxes : /var à 9 Go par défaut, Docker (Coolify ou Dokploy) le sature en quelques semaines avec layers + logs + volumes. Voir le doc dédié : Étendre /var sur LVM dans une VM Proxmox.

Disque à 250 G mais /var ne fait que 9 G

Comportement normal du partitionnement OSBoxes : LVs séparés, /home prend l'essentiel, /var est petit. À corriger après install. Procédure : étendre sda5 jusqu'à 100% (souvent 50 G de rab à la fin du disque), puis pvresize + lvextend -L +50G -r debian12-vg/var.

Références

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment