
QEMU
Article Wikipedia : https://fr.wikipedia.org/wiki/QEMU
QEMU Network
Documentation officielle : https://wiki.qemu.org/Documentation/Networking
Journaux liées à cette note :
Mémento au sujet de QEMU et de sa configuration réseau
Note de type #mémento #mémo au sujet des fonctionnalités network de QEMU.
Pour bien comprendre le fonctionnement de la configuration network de QEMU, il est important de bien saisir deux concepts :
- les "virtual network device" (
-device
) - les "network backend" (
-netdev
)
There are two parts to networking within QEMU:
- the virtual network device that is provided to the guest (e.g. a PCI network card).
- the network backend that interacts with the emulated NIC (e.g. puts packets onto the host's network).
Voici toute la liste des network backend supportés par QEMU :
$ qemu-system-x86_64 -netdev help
Available netdev backend types:
socket
stream
dgram
hubport
tap
user
l2tpv3
bridge
af-xdp
vhost-user
vhost-vdpa
Dans cette note, je m'intéresse uniquement aux backend user, tap et bridge.
Le network backend user
permet uniquement des accès sortant de la machine virtuelle vers Internet, mais pas l'inverse sans configurer un forwarding de port.
La configuration s'effectue via les options -netdev
et -device
:
$ qemu-system-x86_64 \
... \
-netdev user,id=n1 \ # configuration du network backend
-device e1000,netdev=n1 \ # virtual network device
...
La version 2.12 de QEMU (2018) propose une alternative plus simplifiée avec l'option -nic
. Voici une exemple équivalent à la configuration ci-dessus :
$ qemu-system-x86_64 \
... \
-nic user,model=e1000
La version 2.12 de QEMU (2018) propose une alternative plus simplifiée avec l'option -nic
. Voici un exemple équivalent à la configuration ci-dessus :
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
altname enp0s3
altname ens3
altname enx525400123456
inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute eth0
valid_lft 47067sec preferred_lft 47067sec
inet6 fec0::5054:ff:fe12:3456/64 scope site dynamic noprefixroute
valid_lft 86251sec preferred_lft 14251sec
inet6 fe80::5054:ff:fe12:3456/64 scope link noprefixroute
valid_lft forever preferred_lft forever
En approfondissant mes recherches, j'ai appris que quand le network backend user
est configuré, QEMU prend en charge nativement les fonctionnalités DHCP et NAT. Il répond aux requêtes DHCP de la VM démarrée et gère aussi le routage IP en mode NAT.
On peut voir ici deux adresses IPv6 attachées à l'interface eth0
:
fec0::5054:ff:fe12:3456/64
fe80::5054:ff:fe12:3456/64
Une fois développées, ces deux adresses correspondent à :
fec0:0000:0000:0000:5054:00ff:fe12:3456
fe80:0000:0000:0000:5054:00ff:fe12:3456
Après avoir regardé cette vidéo, je pense avoir compris que dans une IPv6, la moitié gauche représente systématiquement un réseau (ici fe80:0000:0000:0000
), nommé aussi "network prefix" ou "routing prefix", tandis que la partie de droite (ici 5054:00ff:fe12:3456
) correspond à une adresse d'interface.
La partie interface de ces deux adresses est identique : 5054:00ff:fe12:3456
.
Cette adresse d'interface est générée par conversion EUI-64 de l'adresse MAC 52:54:00:12:34:56
=> 5054:00ff:fe12:3456
.
Exemple de génération d'une autre adresse IPv6 si j'ajoute une interface réseau supplémentaire à la machine virtuelle :
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:12:34:57 brd ff:ff:ff:ff:ff:ff
altname enp0s4
altname ens4
altname enx525400123457
inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute eth1
valid_lft 86388sec preferred_lft 86388sec
inet6 fec0::5054:ff:fe12:3457/64 scope site dynamic noprefixroute
valid_lft 86389sec preferred_lft 14389sec
inet6 fe80::5054:ff:fe12:3457/64 scope link noprefixroute
valid_lft forever preferred_lft forever
Ici on peut voir que la conversion EUI-64 de 52:54:00:12:34:57
donne 5054:ff:fe12:3457
.
Par rapport au fonctionnement d'IPv4, je trouve que le mécanisme de génération automatique des adresses d'interface réseau d'IPv6 très bien conçu 👌.
Je m'intéresse maintenant aux préfixes d'adresses IPv6 fec0::/10
et fe80::/10
.
Le préfixe fe80::/10
est réservé aux adresses Link-Local. Ces adresses sont automatiquement configurées sur toutes les interfaces IPv6 actives et permettent une communication uniquement au sein du même segment réseau.
Exemple, dans le schéma ci-dessous, tous les serveurs présents sur le réseau A sont joignables via l'adresse Link-Local.
Cependant, les serveurs A n'ont pas la possibilité d'atteindre les serveurs B via Link-Local.
Rocky Linux semble reproduire CentOS de manière plus fidèle que AlmaLinux
Hier, j'ai écrit la note "AlmaLinux ou Rocky Linux ?".
En ce moment, je suis en train d'approfondir mes connaissances sur le fonctionnement des différents network backend de QEMU et j'en ai profité pour comparer le comportement d'Ubuntu, AlmaLinux, Rocky Linux et CentOS.
J'ai lancé QEMU avec le paramètre qemu ... -nic user
avec chacune de ces distributions et voici les résultats de ip addr
dans chacune de ces VMs:
Ubuntu :
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
altname enp0s3
inet 10.0.2.15/24 metric 100 brd 10.0.2.255 scope global dynamic ens3
valid_lft 83314sec preferred_lft 83314sec
inet6 fec0::5054:ff:fe12:3456/64 scope site dynamic mngtmpaddr noprefixroute
valid_lft 86087sec preferred_lft 14087sec
inet6 fe80::5054:ff:fe12:3456/64 scope link
valid_lft forever preferred_lft forever
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
altname enp0s3
altname enx525400123456
inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute ens3
valid_lft 83596sec preferred_lft 83596sec
inet6 fec0::5054:ff:fe12:3456/64 scope site dynamic noprefixroute
valid_lft 86379sec preferred_lft 14379sec
inet6 fe80::5054:ff:fe12:3456/64 scope link noprefixroute
valid_lft forever preferred_lft forever
CentOS :
$ sudo ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
altname enp0s3
altname enx525400123456
inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute ens3
valid_lft 86341sec preferred_lft 86341sec
inet6 fec0::5054:ff:fe12:3456/64 scope site dynamic noprefixroute
valid_lft 86342sec preferred_lft 14342sec
inet6 fe80::5054:ff:fe12:3456/64 scope link noprefixroute
valid_lft forever preferred_lft forever
$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
altname enp0s3
altname ens3
altname enx525400123456
inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic noprefixroute eth0
valid_lft 84221sec preferred_lft 84221sec
inet6 fec0::5054:ff:fe12:3456/64 scope site dynamic noprefixroute
valid_lft 86053sec preferred_lft 14053sec
inet6 fe80::5054:ff:fe12:3456/64 scope link noprefixroute
valid_lft forever preferred_lft forever
Ce que j'observe :
- Rocky Linux et CentOS semblent se comporter de manière identique :
- une interface réseau nommée
ens3
qui signifie : ethernet slot 3 - et les noms alternatifs :
enp0s3
qui signifie : ethernet, PCI bus 0, slot 3enx525400123456
qui signifie : ethernet +x
+ la adresse MAC sans les:
- une interface réseau nommée
- Ubuntu :
- une interface réseau nommée
ens3
- et un nom alternatif :
enp0s3
- une interface réseau nommée
- AlmaLinux :
- une interface réseau nommée
eth0
- et les noms alternatifs :
ens3
enp0s3
enx525400123456
- une interface réseau nommée
Voici les configurations de GRUB_CMDLINE_LINUX_DEFAULT
:
Rocky Linux et CentOS :
GRUB_CMDLINE_LINUX_DEFAULT="console=ttyS0,115200n8 no_timer_check crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M"
GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200n8 no_timer_check biosdevname=0 net.ifnames=0"
Ubuntu :
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
Conclusion de cette analyse : il me semble que Rocky Linux cherche à reproduire CentOS de manière très fidèle, alors qu'AlmaLinux se permet davantage de libertés dans son approche.
Journal du dimanche 09 mars 2025 à 10:37
Je viens de publier le playground suivant : qemu-fedora-workstation-playground
.
Je suis particulièrement satisfait d'avoir mis en place ce playground, car il concrétise plusieurs objectifs que je m'étais fixés depuis longtemps :
- Cela fait plusieurs années que je souhaite à remplacer Vagrant par une solution plus minimaliste. Je souhaite réduire mon utilisation d'outils basés sur Ruby.
J'ai, par exemple, effectué une tentative en février 2023 basée sur virsh. - Utiliser une VM Fedora Workstation pour tester ma configuration dotfiles basée sur chezmoi :
- Par exemple ici
- et ici : How do you test your configuration on a bare OS? Docker? Distrobox? Vagrant?
Finalement, la solution était assez simple à mettre en place et elle est très performante.
Ma VM Fedora Workstation affiche l'écran d'ouverture de session GNOME Display Manager en moins de 19s.
Voici une traduction en français de qemu-fedora-workstation-playground
.
Voici les dépendances à installer :
$ sudo dnf install -y \
qemu-system-x86 \
qemu-system-common \
qemu-img \
qemu-img-extras \
cloud-utils \
mesa-dri-drivers \
libguestfs-tools
Pour simplifier, la méthode que je présente est basée uniquement sur QEMU.
Je télécharge la version 41 de Fedora dans sa version "cloud" :
$ wget https://download.fedoraproject.org/pub/fedora/linux/releases/41/Cloud/x86_64/images/Fedora-Cloud-Base-Generic-41-1.4.x86_64.qcow2 -O fedora-41-base.qcow2
À partir de cette image de base, je crée une image de type couche (layer) que j'utilise pour effectuer mes opérations sur la machine virtuelle. Cette approche me permet de revenir facilement en arrière (rollback) en cas de problème, annulant ainsi les modifications apportées à la VM.
$ qemu-img create -f qcow2 -b fedora-41-base.qcow2 -F qcow2 fedora-working-layer.qcow2
$ ls -s1h *.qcow2
469M fedora-41-base.qcow2
196K fedora-working-layer.qcow2
Je prépare un fichier cloud-init qui permet de configurer le mot de passe et ma clé SSH :
$ cat <<'EOF' > cloud-init.yaml
#cloud-config
users:
- name: fedora
plain_text_passwd: password
lock_passwd: false
shell: /bin/bash
sudo: ALL=(ALL) NOPASSWD:ALL
ssh_authorized_keys:
- ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDEzyNFlEuHIlewK0B8B0uAc9Q3JKjzi7myUMhvtB3JmA2BqHfVHyGimuAajSkaemjvIlWZ3IFddf0UibjOfmQH57/faxcNEino+6uPRjs0pFH8sNKWAaPX1qYqOFhB3m+om0hZDeQCyZ1x1R6m+B0VJHWQ3pxFaxQvL/K+454AmIWB0b87MMHHX0UzUja5D6sHYscHo57rzJI1fc66+AFz4fcRd/z+sUsDlLSIOWfVNuzXuGpKYuG+VW9moiMTUo8gTE9Nam6V2uFwv2w3NaOs/2KL+PpbY662v+iIB2Yyl4EP1JgczShOoZkLatnw823nD1muC8tYODxVq7Xf7pM/NSCf3GPCXtxoOEqxprLapIet0uBSB4oNZhC9h7K/1MEaBGbU+E2J5/5hURYDmYXy6KZWqrK/OEf4raGqx1bsaWcONOfIVXbj3zXTUobsqSkyCkkR3hJbf39JZ8/6ONAJS/3O+wFZknFJYmaRPuaWiLZxRj5/gw01vkNVMrogOIkQtzNDB6fh2q27ghSRkAkM8EVqkW21WkpB7y16Vzva4KSZgQcFcyxUTqG414fP+/V38aCopGpqB6XjnvyRorPHXjm2ViVWbjxmBSQ9aK0+2MeKA9WmHN0QoBMVRPrN6NBa3z20z1kMQ/qlRXiDFOEkuW4C1n2KTVNd6IOGE8AufQ== contact@stephane-klein.info
ssh_pwauth: true
EOF
$ cloud-localds cloud-init.img cloud-init.yaml
Lancement de la VM avec :
- accélération graphique
- configuration d'une interface réseau virtuelle avec la redirection d'un port ssh
- partage d'un dossier entre l'hôte et la VM
$ qemu-system-x86_64 \
-m 8G \
-smp 4 \
-enable-kvm \
-drive file=fedora-working-layer.qcow2,format=qcow2 \
-device virtio-vga-gl \
-display gtk,gl=on \
-nic user,hostfwd=tcp::2222-:22 \
-drive file=cloud-init.img,format=raw \
-fsdev local,id=fsdev0,path=$(pwd)/shared/,security_model=mapped-file \
-device virtio-9p-pci,fsdev=fsdev0,mount_tag=host_share
Cette VM est accessible via ssh, comme avec Vagrant :
$ ssh-keygen -R "[localhost]:2222"
$ ssh -o StrictHostKeyChecking=no -p 2222 fedora@localhost
Warning: Permanently added '[localhost]:2222' (ED25519) to the list of known hosts.
[fedora@localhost ~]$
Et voici comment à partir de la VM je peux monter le dossier partagé :
[fedora@localhost ~]$ sudo mkdir -p /mnt/host_share
[fedora@localhost ~]$ sudo mount -t 9p -o trans=virtio,version=9p2000.L host_share /mnt/host_share
[fedora@localhost ~]$ ls /mnt/host_share/ -lha
total 0
drwxr-xr-x. 1 fedora fedora 16 Mar 9 11:44 .
drwxr-xr-x. 1 root root 20 Mar 9 11:45 ..
-rw-r--r--. 1 fedora fedora 0 Mar 9 11:44 .gitkeep
J'ai ensuite lancé les commandes suivantes pour installer les packages pour avoir une Fedora Workstation :
$ sudo localectl set-keymap fr-bepo # J'utilise un clavier Bépo
$ sudo dnf update -y
$ sudo dnf install -y @gnome-desktop @workstation-product gnome-session-wayland-session
$ sudo systemctl set-default graphical.target
$ sudo reboot
Et voici le résultat :
Je vais pouvoir intégrer cette méthode à https://github.com/stephane-klein/dotfiles afin de développer et tester mes scripts d'installation chezmoi dans un environnement contrôlé et reproductible, garantissant un comportement déterministe. Desktop configuration as code 🙂.
Le qemu-fedora-workstation-playground
contient des scripts pour automatiser les opérations présentées :
/scripts/up.sh
/scripts/enter-in-vm.sh
/scripts/setup-shared-folder.sh
/scripts/install-vm-workstation.sh
Je pense que cette méthode pourra remplacer Vagrant dans plusieurs de mes projets.