erplibre/script/qemu/README.base.md

QEMU/KVM — Linux VM deployment (Ubuntu / Debian / Fedora)

deploy_qemu.py deploys a Linux VM (libvirt/KVM) from an official cloud image, using qemu-img + cloud-init + virt-install. Pick the distribution with --distro (ubuntu default, debian, fedora) and the release with --version; run --list-images to see the full catalogue with minimum specs. It:

1. Downloads the cloud image by itself (cached, no double download).
2. Converts it to a dedicated qcow2 working disk and resizes it.
3. Generates user-data / meta-data and builds the seed.iso (cloud-init).
4. Runs virt-install importing the disk + the seed as a CD-ROM.
5. Waits for the DHCP lease and prints the SSH command.

QEMU/KVM — Déploiement de VM Linux (Ubuntu / Debian / Fedora)

deploy_qemu.py déploie une VM Linux (libvirt/KVM) à partir d'une image cloud officielle, via qemu-img + cloud-init + virt-install. Choisissez la distribution avec --distro (ubuntu par défaut, debian, fedora) et la version avec --version ; --list-images affiche tout le catalogue avec les specs minimales. Il :

1. Télécharge lui-même l'image cloud (mise en cache, sans double téléchargement).
2. La convertit en un disque de travail qcow2 dédié et le redimensionne.
3. Génère user-data / meta-data et construit le seed.iso (cloud-init).
4. Lance virt-install en important le disque + le seed en CD-ROM.
5. Attend le bail DHCP et affiche la commande SSH.

Prerequisites

• A host with KVM available (bare-metal or nested virtualization enabled).
• sudo rights (the deployment writes to /var/lib/libvirt/images and drives libvirt).

Installation

The script auto-installs the missing pieces it needs: on first run it detects your package manager (apt / dnf / pacman / zypper / brew), lists the missing components (the client tools, plus the libvirt daemon and the QEMU system emulator), asks for confirmation, installs them with sudo, then enables and starts libvirtd. Use -y to accept automatically or --no-install-deps to disable this behaviour.

To install everything manually on Ubuntu/Debian (recommended full KVM stack):

Prérequis

• Un hôte disposant de KVM (bare-metal ou virtualisation imbriquée activée).
• Les droits sudo (le déploiement écrit dans /var/lib/libvirt/images et pilote libvirt).

Installation

Le script installe automatiquement les composants manquants : au premier lancement, il détecte votre gestionnaire de paquets (apt / dnf / pacman / zypper / brew), liste les composants absents (les outils clients, ainsi que le démon libvirt et l'émulateur QEMU système), demande confirmation, les installe avec sudo, puis active et démarre libvirtd. Utilisez -y pour accepter automatiquement ou --no-install-deps pour désactiver ce comportement.

Pour tout installer manuellement sur Ubuntu/Debian (pile KVM complète recommandée) :

sudo apt install qemu-utils virtinst libvirt-clients cloud-image-utils \
    libvirt-daemon-system qemu-system-x86
sudo systemctl enable --now libvirtd
sudo usermod -aG libvirt,kvm "$USER"   # re-login / reconnectez-vous

libvirt-daemon-system provides the libvirtd daemon (and the /var/run/libvirt/libvirt-sock socket) and qemu-system-x86 the emulator — without them virt-install fails with "Failed to connect socket to '/var/run/libvirt/libvirt-sock'". The script installs and starts them for you; this manual command is only needed if you prefer to prepare the host yourself or run with --no-install-deps.

Usage

Simplest form — the image is downloaded automatically (path derived from --version, cached in /var/lib/libvirt/images/iso):

libvirt-daemon-system fournit le démon libvirtd (et le socket /var/run/libvirt/libvirt-sock) et qemu-system-x86 l'émulateur — sans eux virt-install échoue avec « Failed to connect socket to '/var/run/libvirt/libvirt-sock' ». Le script les installe et les démarre pour vous ; cette commande manuelle n'est utile que si vous préférez préparer l'hôte vous-même ou utiliser --no-install-deps.

Utilisation

Forme la plus simple — l'image est téléchargée automatiquement (chemin déduit de --version, mis en cache dans /var/lib/libvirt/images/iso) :

sudo ./script/qemu/deploy_qemu.py --name test-vm --version 24.04 \
    --ssh-key ~/.ssh/id_ed25519.pub

Download (and verify) an image without creating a VM:

Télécharger (et vérifier) une image sans créer de VM :

sudo ./script/qemu/deploy_qemu.py --download-only --version 24.04 --verify

Deploy with an interactive password instead of an SSH key:

Déployer avec un mot de passe interactif au lieu d'une clé SSH :

sudo ./script/qemu/deploy_qemu.py --name test-vm --version 24.04 --ask-password

Larger VM (8 GB RAM, 8 vCPU, 120 GB disk), overwriting an existing disk:

VM plus grande (8 Go RAM, 8 vCPU, disque 120 Go), en écrasant un disque existant :

sudo ./script/qemu/deploy_qemu.py --name test-vm --version 24.04 \
    --memory 8192 --vcpus 8 --disk-size 120G --ask-password --force

Preview what would happen, without doing anything (no sudo, no download):

Prévisualiser ce qui serait fait, sans rien exécuter (sans sudo, sans téléchargement) :

./script/qemu/deploy_qemu.py --name test-vm --version 24.04 --dry-run

Non-interactive deployment (accept dependency install automatically):

Déploiement non interactif (accepte automatiquement l'installation des dépendances) :

sudo ./script/qemu/deploy_qemu.py --name test-vm --version 24.04 \
    --ssh-key ~/.ssh/id_ed25519.pub -y

Catalog, per architecture (deploy_qemu.py is the source of truth):

Distro	Versions	amd64	arm64	s390x
ubuntu	24.04 (default), 25.10, 26.04	✔	✔	✔
debian	11, 12 (default), 13	✔	✔	—
fedora	41, 42 (default), 43, 44	✔	✔	43 only
almalinux	9 (default), 10	✔	✔	✔
rocky	9, 10 (default)	✔	✔	✔
opensuse	16.0 (default), tumbleweed	✔	✔	✔
arch	latest	✔	—	—

Fedora builds s390x only for the current release, and on a separate tree (fedora-secondary) — hence the single version there.

opensuse covers two distinct products, not two versions of one. Leap 16.0 is numbered and stable (SLE base) and is the default. tumbleweed is the rolling one, kept as a bellwether for breakage to come: its snapshot drift is real, and it demands a full zypper dup before anything can be installed.

Both ship a qpdf above the pikepdf threshold, so the half-hour qpdf build never runs there — which matters under s390x emulation.

Provide an explicit image path as a positional argument to override the automatic download location.

Ubuntu 20.04 and 22.04 were dropped on every architecture: pikepdf needs qpdf 12.2, whose build requires C++20, and focal ships GCC 9 — it does not even publish g++-10 for s390x. Python 3.8, node 10, cargo 0.67 and OpenSSL 1.1.1 each had a workaround; the pile of them did not.

After deployment

Catalogue, par architecture (deploy_qemu.py fait autorité) :

Distro	Versions	amd64	arm64	s390x
ubuntu	24.04 (défaut), 25.10, 26.04	✔	✔	✔
debian	11, 12 (défaut), 13	✔	✔	—
fedora	41, 42 (défaut), 43, 44	✔	✔	43 seule
almalinux	9 (défaut), 10	✔	✔	✔
rocky	9, 10 (défaut)	✔	✔	✔
opensuse	16.0 (défaut), tumbleweed	✔	✔	✔
arch	latest	✔	—	—

Fedora ne construit s390x que pour la version courante, et sur une arborescence à part (fedora-secondary) — d'où la version unique.

opensuse recouvre deux produits distincts, pas deux versions du même. Leap 16.0 est numérotée et stable (base SLE) : c'est le défaut. tumbleweed est la rolling, gardée comme banc d'essai des ruptures à venir — sa dérive d'instantanés est réelle, et elle impose un zypper dup complet avant toute installation.

Les deux livrent un qpdf au-dessus du seuil de pikepdf : la compilation de qpdf, une demi-heure, ne s'y déclenche jamais — ce qui compte sous émulation s390x.

Fournissez un chemin d'image en argument positionnel pour surcharger l'emplacement de téléchargement automatique.

Les Ubuntu 20.04 et 22.04 sont abandonnées sur toutes les architectures : pikepdf réclame qpdf 12.2, dont la compilation exige C++20, et focal livre GCC 9 — elle ne publie même pas de g++-10 pour s390x. Python 3.8, node 10, cargo 0.67 et OpenSSL 1.1.1 avaient chacun leur contournement ; leur accumulation, non.

Après le déploiement

virsh list --all
virsh console test-vm                    # Ctrl+] to quit / pour quitter
virsh domifaddr test-vm --source lease   # find the IP / trouver l'IP
ssh erplibre@<IP>

The default user is erplibre (change it with --user).

Via the TODO menu

The script is integrated into the interactive assistant. Run make todo (or ./script/todo/todo.py), then go to Execute → Deploy → QEMU/KVM - Deploy an Ubuntu VM (libvirt). From there you can deploy a VM, preview a dry-run, download an image, list VMs and show a VM IP address — the menu asks for the parameters and builds the command for you.

When a VM is graphical, the menu also offers a check list of development tools: PyCharm (installed from the official JetBrains archive into /opt/pycharm, its launcher opening the ERPLibre checkout), Android Studio (/opt/android-studio, command studio or android-studio; x86_64 only — Google publishes no Linux aarch64 build) and a set of suggested GNOME extensions.

The extension packages of the distribution are installed but left disabled — their UUID is not reliably known, and the Extension Manager is there to pick from. Three extensions named by UUID are installed and enabled, straight from extensions.gnome.org: gTile, Freon and Tracker. The archive is fetched for the GNOME Shell version actually running in the VM — the same endpoint serves gTile v59 for GNOME 46 and v62 for GNOME 48, so a frozen URL would install a build made for another release. A mismatched build is never loaded by GNOME anyway: it compares metadata.json with its own version and shows the extension as outdated rather than breaking the session.

The tools are installed before the clone and the ERPLibre install, and the order matters: PyCharm writes the repository's .idea/ the first time it opens the project, and the install that follows runs pycharm_configuration.py on it (update_env_version.pycharm_update(), which skips silently when there is no .idea yet). So on a fresh VM: open PyCharm once on ~/git/erplibre, close it, then re-run make install_odoo_18.

Each tool is filtered per VM — by architecture and by desktop flavour — and its disk cost is added to the plan before anything is created.

Main options

• --distro — ubuntu (default), debian or fedora.
• --version — release for the distro (default: the distro's default).
• --list-images — print all distros/versions and their specs, then exit.
• --image-dir — image cache directory (default /var/lib/libvirt/images/iso).
• --download-only — download the image then exit (no VM).
• --name — VM name (required for deployment).
• --memory, --vcpus, --disk-size — VM sizing. When omitted, --memory and --disk-size default to the minimum required by the chosen version (libosinfo values, see --list-images: Ubuntu 24.04+ → 3072 MB/20G, Debian → 1024 MB/10G, Fedora → 2048 MB/15G); --vcpus defaults to 2.
• --ssh-key, --ask-password, --password-hash — authentication.
• -y / --assume-yes — auto-accept dependency installation.
• --no-install-deps — never auto-install dependencies.
• --dry-run — show the commands without executing anything.
• --force — overwrite the existing working qcow2 disk.
• --lang — language of the SSH login guide, fr (default) or en. The TODO menu passes its own language.
• --erplibre-dir — where ERPLibre will live in the VM (~/git/erplibre, or /opt/erplibre in production). Adds the ERPLibre section to the login guide; omitted, that section is left out.
• --erplibre-make — the make target that installed the VM (e.g. install_odoo_18), shown in the guide as the way to update it.
• --no-git-identity — do not copy the host's user.name, user.email and core.editor into the VM's ~/.gitconfig.

Run ./script/qemu/deploy_qemu.py --help for the full list.

Login guide (/etc/motd)

Every VM greets you, at each interactive SSH login, with the commands of its own distribution — apt, dnf, zypper or pacman — plus the ERPLibre ones (edit the server, restart it, update modules, update Odoo, inspect the instance, open the TODO menu). It is written by cloud-init, so it is there from the first boot: before ERPLibre is installed, and still there if that installation fails, which is exactly when you log in by hand.

--dry-run prints the generated guide along with the rest of the user-data. The guide is not shown to ssh host 'command', so it never pollutes an installation log.

The host's git identity travels with it, into the VM's ~/.gitconfig: a commit made in the VM then carries your name instead of erplibre@<vm-name>. The editor follows the same route — core.editor, the config.conf line of the guide, and the package installed in the VM all come from one table, so the guide never names a command the VM does not have.

L'utilisateur par défaut est erplibre (modifiable avec --user).

Via le menu TODO

Le script est intégré à l'assistant interactif. Lancez make todo (ou ./script/todo/todo.py), puis allez dans Execute → Deploy → QEMU/KVM - Deploy an Ubuntu VM (libvirt). De là, vous pouvez déployer une VM, prévisualiser un dry-run, télécharger une image, lister les VM et afficher l'IP d'une VM — le menu demande les paramètres et construit la commande pour vous.

Quand une VM est graphique, le menu propose en plus une liste à cocher d'outils de développement : PyCharm (posé depuis l'archive officielle JetBrains dans /opt/pycharm, son lanceur ouvrant le dépôt ERPLibre), Android Studio (/opt/android-studio, commande studio ou android-studio ; x86_64 seulement — Google ne publie aucune archive Linux aarch64) et un jeu d'extensions GNOME suggérées.

Les extensions empaquetées par la distribution sont installées sans être activées — leur UUID n'est pas connu de façon fiable, et le gestionnaire d'extensions est là pour choisir. Trois extensions nommées par leur UUID sont, elles, installées et activées, directement depuis extensions.gnome.org : gTile, Freon et Tracker. L'archive est prise pour la version de GNOME Shell qui tourne vraiment dans la VM — le même point d'entrée sert gTile v59 en GNOME 46 et v62 en GNOME 48, si bien qu'une URL figée poserait une version faite pour une autre release. Une archive mal appariée n'est de toute façon jamais chargée par GNOME : il compare metadata.json à sa propre version et affiche l'extension comme obsolète plutôt que de casser la session.

Les outils sont posés avant le clone et l'installation d'ERPLibre, et l'ordre compte : PyCharm écrit le .idea/ du dépôt à la première ouverture du projet, et l'installation qui suit y lance pycharm_configuration.py (update_env_version.pycharm_update(), qui se tait tant qu'il n'y a pas de .idea). Sur une VM neuve : ouvrir PyCharm une fois sur ~/git/erplibre, le fermer, puis relancer make install_odoo_18.

Chaque outil est filtré VM par VM — architecture et saveur de bureau — et sa place disque s'ajoute au plan avant que rien ne soit créé.

Principales options

• --distro — ubuntu (défaut), debian ou fedora.
• --version — version de la distro (défaut : celle par défaut de la distro).
• --list-images — affiche toutes les distros/versions et leurs specs.
• --image-dir — répertoire de cache des images (défaut /var/lib/libvirt/images/iso).
• --download-only — télécharge l'image puis quitte (sans VM).
• --name — nom de la VM (requis pour le déploiement).
• --memory, --vcpus, --disk-size — dimensionnement de la VM. Omis, --memory et --disk-size prennent le minimum requis par la version choisie (valeurs libosinfo, voir --list-images : Ubuntu 24.04+ → 3072 Mo/20G, Debian → 1024 Mo/10G, Fedora → 2048 Mo/15G) ; --vcpus vaut 2 par défaut.
• --ssh-key, --ask-password, --password-hash — authentification.
• -y / --assume-yes — accepte automatiquement l'installation des dépendances.
• --no-install-deps — n'installe jamais les dépendances automatiquement.
• --dry-run — affiche les commandes sans rien exécuter.
• --force — écrase le disque de travail qcow2 existant.
• --lang — langue du guide affiché à la connexion SSH, fr (défaut) ou en. Le menu TODO passe la sienne.
• --erplibre-dir — où ERPLibre sera installé dans la VM (~/git/erplibre, ou /opt/erplibre en production). Ajoute la section ERPLibre au guide de connexion ; omis, cette section est laissée de côté.
• --erplibre-make — la cible make qui a installé la VM (ex. install_odoo_18), reprise dans le guide pour la mettre à jour.
• --no-git-identity — ne recopie pas les user.name, user.email et core.editor de l'hôte dans le ~/.gitconfig de la VM.

Lancez ./script/qemu/deploy_qemu.py --help pour la liste complète.

Guide de connexion (/etc/motd)

Chaque VM accueille celui qui s'y connecte en SSH avec les commandes de sa distribution — apt, dnf, zypper ou pacman — et celles d'ERPLibre : éditer le serveur, le redémarrer, mettre à jour des modules, mettre à jour Odoo, inspecter l'instance, ouvrir le menu TODO. Il est écrit par cloud-init, donc présent dès le premier démarrage : avant l'installation d'ERPLibre, et encore là si elle échoue — le moment où l'on se connecte justement à la main.

--dry-run affiche le guide généré avec le reste du user-data. Il ne s'affiche PAS pour un ssh hôte 'commande' : les journaux d'installation restent nets.

L'identité git de l'hôte voyage avec lui, dans le ~/.gitconfig de la VM : un commit fait dans la VM porte alors votre nom plutôt que erplibre@<nom-de-vm>. L'éditeur suit le même chemin — core.editor, la ligne config.conf du guide et le paquet installé dans la VM viennent d'une seule table, de sorte que le guide ne nomme jamais une commande absente.

Managing VMs

List, stop and remove VMs (the qcow2 disk under /var/lib/libvirt/images is kept unless you delete it):

Gestion des VM

Lister, arrêter et supprimer les VM (le disque qcow2 sous /var/lib/libvirt/images est conservé tant que vous ne le supprimez pas) :

sudo virsh list --all          # toutes les VM et leur état / all VMs and state
sudo virsh shutdown <nom-vm>   # arrêt propre ACPI / graceful shutdown
sudo virsh destroy <nom-vm>    # arrêt forcé / force off (pull the plug)
sudo virsh undefine <nom-vm>   # supprime la définition / remove definition
sudo virsh domifaddr <nom-vm>  # adresse IP de la VM / VM IP address

destroy only powers the VM off (disk kept); undefine removes its definition. To fully recreate a VM with the same name, destroy + undefine it first, or redeploy with --force.

SSH access from another machine (ProxyJump)

With the default NAT network the VM is reachable only from the KVM host. To reach it from another machine without changing the network, use the host as a jump host (it already reaches the VM). Get the VM IP with sudo virsh domifaddr <nom-vm>, then from the other machine:

destroy ne fait qu'éteindre la VM (disque conservé) ; undefine supprime sa définition. Pour recréer proprement une VM du même nom, faites destroy + undefine d'abord, ou redéployez avec --force.

Accès SSH depuis une autre machine (ProxyJump)

Avec le réseau NAT par défaut, la VM n'est joignable que depuis l'hôte KVM. Pour l'atteindre depuis une autre machine sans toucher au réseau, utilisez l'hôte comme rebond (il joint déjà la VM). Récupérez l'IP de la VM avec sudo virsh domifaddr <nom-vm>, puis depuis l'autre machine :

# Rebond SSH vers la VM / jump through the KVM host
ssh -J user@<ip-hote> erplibre@<ip-vm>

# Tunnel d'un service, ex. Odoo 8069 / tunnel a service, then http://localhost:8069
ssh -L 8069:<ip-vm>:8069 user@<ip-hote>

To make it permanent, add this to ~/.ssh/config on the other machine (then just ssh myvm):

Pour le rendre permanent, ajoutez ceci à ~/.ssh/config sur l'autre machine (ensuite ssh myvm suffit) :

Host myvm
    HostName <ip-vm>            # ex. 192.168.122.50 (reseau NAT)
    User erplibre
    ProxyJump user@<ip-hote>    # IP LAN de l'hote KVM

This works over Wi-Fi and needs no VM shutdown — the simplest option for personal access. Prefer a bridge (below) if the VM must be a full server exposed on the LAN.

QEMU inside QEMU (nested) & exposing the VM via a bridge

If the KVM host is itself a VM (QEMU-in-QEMU), the deployment works only when nested virtualization is enabled on the outer/physical host and the middle VM uses CPU mode host-passthrough. Check from inside the KVM host (the first command must be non-empty):

Ça marche en Wi-Fi et sans arrêter la VM — l'option la plus simple pour un accès personnel. Préférez un pont (ci-dessous) si la VM doit être un serveur à part entière exposé sur le LAN.

QEMU dans QEMU (imbriqué) & exposer la VM via un pont

Si l'hôte KVM est lui-même une VM (QEMU dans QEMU), le déploiement ne fonctionne que si la virtualisation imbriquée est activée sur l'hôte physique et que la VM intermédiaire utilise le mode CPU host-passthrough. Vérifiez depuis l'hôte KVM (la première commande doit être non vide) :

grep -E -o '(vmx|svm)' /proc/cpuinfo | sort -u   # extensions visibles / visible
# Sur l'hote PHYSIQUE / on the PHYSICAL host:
cat /sys/module/kvm_intel/parameters/nested      # Intel -> Y/1
cat /sys/module/kvm_amd/parameters/nested        # AMD   -> Y/1

To enable nesting on the physical host (Intel shown; use kvm_amd on AMD), then recreate the middle VM with host-passthrough:

Pour activer l'imbrication sur l'hôte physique (Intel montré ; kvm_amd sur AMD), puis recréer la VM intermédiaire en host-passthrough :

echo "options kvm_intel nested=1" | sudo tee /etc/modprobe.d/kvm-nested.conf
sudo modprobe -r kvm_intel && sudo modprobe kvm_intel   # ou / or reboot

On s390x and arm64 the parameter lives on the kvm module itself, not on kvm_intel / kvm_amd — and /sys/module/kvm/parameters/nested does not even exist on x86. Reading the wrong file returns a reassuring 0 that commands nothing:

Sur s390x et arm64, le paramètre vit sur le module kvm lui-même, et non sur kvm_intel / kvm_amd — et /sys/module/kvm/parameters/nested n'existe même pas sur x86. Lire le mauvais fichier renvoie un 0 rassurant qui ne commande rien :

echo "options kvm nested=1" | sudo tee /etc/modprobe.d/kvm-nested.conf
sudo modprobe -r kvm && sudo modprobe kvm               # ou / or reboot

nested on a machine means « let MY guests run VMs ». To accelerate a VM created on host H, the setting belongs to the hypervisor above H, not to H itself. The one command that settles it, run on H:

nested sur une machine signifie « j'autorise MES invités à faire tourner des VM ». Pour accélérer une VM créée sur l'hôte H, le réglage appartient à l'hyperviseur au-dessus de H, pas à H. La commande qui tranche, sur H :

ls -l /dev/kvm     # absent -> pas d'imbrication, tout sera émulé

Measured on an s390x host that was itself a KVM guest without nesting: /dev/kvm absent, virsh dumpxml showing <domain type='qemu'>, and a 7 min 30 boot instead of well under a minute. systemd-detect-virt inside the VM is not proof of acceleration — on s390x, QEMU fabricates the STSI answer and reports kvm even under TCG. Only <domain type=…> on the host is conclusive.

If nesting is unavailable, QEMU still runs via software emulation (TCG) — it works but is slow.

Mesuré sur un hôte s390x lui-même invité KVM sans imbrication : /dev/kvm absent, virsh dumpxml affichant <domain type='qemu'>, et un démarrage de 7 min 30 au lieu de bien moins d'une minute. systemd-detect-virt dans la VM ne prouve pas l'accélération — sur s390x, QEMU fabrique la réponse STSI et annonce kvm même en TCG. Seul <domain type=…> sur l'hôte fait foi.

Bridge for external access

A NAT VM is isolated; a bridged VM gets an IP directly on the LAN, reachable by any machine. On the KVM host, create a bridge br0 over the physical NIC (wired only — Wi-Fi cannot be bridged). netplan (Ubuntu server) — replace enp3s0 with your interface:

Si l'imbrication est indisponible, QEMU tourne quand même en émulation logicielle (TCG) — ça marche mais c'est lent.

Pont pour l'accès externe

Une VM en NAT est isolée ; une VM pontée obtient une IP directement sur le LAN, joignable par n'importe quelle machine. Sur l'hôte KVM, créez un pont br0 sur la carte physique (filaire uniquement — le Wi-Fi ne se ponte pas). netplan (Ubuntu serveur) — remplacez enp3s0 par votre interface :

# /etc/netplan/01-br0.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0: {dhcp4: no, dhcp6: no}
  bridges:
    br0:
      interfaces: [enp3s0]
      dhcp4: yes
      parameters: {stp: false, forward-delay: 0}

Apply safely (auto-reverts if you lose the connection) and verify — or use NetworkManager (Ubuntu desktop):

Appliquez avec filet de sécurité (annulation auto en cas de coupure) et vérifiez — ou via NetworkManager (Ubuntu bureau) :

# netplan
sudo netplan try && sudo netplan apply
ip addr show br0        # br0 porte l'IP du LAN / br0 holds the LAN IP

# NetworkManager (alternative)
nmcli con add type bridge ifname br0 con-name br0
nmcli con add type ethernet ifname enp3s0 master br0 con-name br0-port
nmcli con modify br0 ipv4.method auto
nmcli con down "Wired connection 1" ; nmcli con up br0

Then attach the VM to the bridge — either at creation:

Rattachez ensuite la VM au pont — soit à la création :

sudo ./script/qemu/deploy_qemu.py --name <nom-vm> --version 24.04 \
    --ssh-key ~/.ssh/id_ed25519.pub --network bridge=br0,model=virtio -y --force

or by editing a VM already created: stop it, replace its <interface> block (type='network' / <source network='default'/> → type='bridge' / <source bridge='br0'/>), then start it again:

soit par édition d'une VM déjà créée : arrêtez-la, remplacez son bloc <interface> (type='network' / <source network='default'/> → type='bridge' / <source bridge='br0'/>), puis redémarrez-la :

sudo virsh shutdown <nom-vm>
sudo virsh edit <nom-vm>        # mettre l'interface en bridge=br0
sudo virsh start <nom-vm>
sudo virsh domifaddr <nom-vm>   # nouvelle IP LAN / new LAN IP

The VM now gets a LAN IP from your router, reachable by other machines. From the Internet you additionally need a port-forward on your router (or a VPN); in a nested setup the outer host must also forward/expose the middle VM.

La VM obtient maintenant une IP LAN de votre routeur, joignable par les autres machines. Depuis Internet, il faut en plus une redirection de port sur votre routeur (ou un VPN) ; en configuration imbriquée, l'hôte externe doit aussi rediriger/exposer la VM intermédiaire.