Outil CLI
qemus/qemu avatar
qemus/qemu

QEMU dans un conteneur Docker, avec console web

qemus/qemu offre une implémentation open source exploitable en conditions réelles avec une structure réutilisable.

2 130 étoiles248 forksShellMIT
GitHub

En bref

De quoi s’agit-il ?
Exécuter QEMU dans un conteneur Docker, contrôler la VM depuis le navigateur et utiliser l'accélération KVM si l'hôte le permet.
À qui s’adresse-t-il ?
Le README ne liste aucun utilisateur précis, benchmark ou résultat de performance au-delà de sa liste de fonctionnalités. Il renvoie vers des dépôts séparés pour Windows, macOS, ARM64 et Proxmox, et vers docs/environment.md pour l'ensemble des réglages.
Puis-je l’utiliser commercialement ?
Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
Est-il encore maintenu ?
Oui. Les derniers commits datent d’il y a 8 jours.
En quel langage est-il écrit ?
Principalement Shell, d’après les statistiques de langage de GitHub.

Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.

ANALYSE OPEN SOURCE APPROFONDIE

QEMU conteneurisé avec console navigateur

Le dépôt empaquette QEMU dans un conteneur Docker. Selon le README, il peut exécuter des machines virtuelles dans un conteneur, prendre en charge presque tous les formats de disque et d'image, et fournir un visualiseur web pour contrôler la VM. Il liste l'accélération KVM pour des performances quasi natives, une allocation personnalisable du CPU, de la mémoire et du stockage, le ballonnement mémoire dynamique, le passage de périphériques USB, le partage de dossiers de l'hôte, plusieurs modes de réseau et des téléchargements automatiques pour les distributions Linux courantes. L'image est publiée sous le nom qemux/qemu sur Docker Hub, mais le README ne donne ni numéros de version ni dates de construction.

Prérequis et limitation KVM

Le README exige Docker ou Podman sur un hôte Linux avec support KVM, ou Docker Desktop ou Podman Desktop sur Windows 11 avec virtualisation imbriquée activée. Il demande aussi au moins 2 Go de RAM et 64 Go d'espace disque libre. Une note indique que Docker Desktop sur Linux, macOS et Windows 10 ne fournit actuellement pas l'accès KVM aux conteneurs et n'est donc pas pris en charge. Pour vérifier KVM, le README suggère d'installer cpu-checker et d'exécuter kvm-ok, et de vérifier que /dev/kvm existe ; si kvm-ok réussit mais que le conteneur signale toujours l'absence de KVM, ajouter temporairement privileged: true au fichier Compose peut écarter un problème d'accès aux périphériques. La licence est MIT ; le texte de licence fournit le logiciel 'tel quel' sans garantie et ne mentionne ni support ni garanties de sécurité.

Démarrer le conteneur

Le README propose trois environnements d'exécution. Un exemple Docker Compose définit BOOT sur mint, ajoute /dev/kvm et /dev/net/tun comme périphériques, accorde NET_ADMIN, publie le port 8006 et monte ./qemu vers /storage. La commande Docker CLI équivalente passe les mêmes options avec -e, --device, --cap-add, -p et -v. Pour Kubernetes, il fournit une URL kubectl apply vers un fichier kubernetes.yml. Le README mentionne aussi GitHub Codespaces comme option, mais sans instructions. Le visualiseur web est attendu sur le port 8006, et le README demande aux utilisateurs de terminer l'installation de l'invité dans le navigateur.

Choisir le système d'exploitation

La variable d'environnement BOOT sélectionne l'invité. Le README contient un tableau de 23 valeurs, de alma et alpine à ubuntu, xubuntu, zima et zorin, chacune avec une taille d'image. Au lieu d'une valeur prédéfinie, BOOT peut être défini sur une URL d'un fichier .img, .raw, .iso, .qcow2, .vmdk, .vhd, .vhdx ou .vdi ; les variantes compressées comme .img.gz et .qcow2.xz sont extraites automatiquement. Une image locale peut être montée par bind sur /boot.iso, /boot.img ou /boot.qcow2, auquel cas BOOT est ignoré.

Réglages CPU, mémoire et stockage

Par défaut, la VM utilise 2 cœurs CPU, 2 Go de RAM et un disque de 64 Go. RAM_SIZE et CPU_CORES ajustent la mémoire et les cœurs, tandis que DISK_SIZE modifie la capacité du disque et peut aussi servir à agrandir un disque existant ; le README précise que l'espace supplémentaire apparaît comme non alloué et que la partition doit être étendue manuellement dans l'invité. Le chemin de stockage est contrôlé en montant un volume vers /storage. Des disques supplémentaires peuvent être ajoutés avec DISK2_SIZE et DISK3_SIZE et des montages de volumes séparés. Le mode de démarrage est UEFI par défaut, avec BOOT_MODE=legacy pour changer. Le contrôleur de disque par défaut est virtio-scsi ; DISK_TYPE=blk passe à virtio-blk, et DISK_TYPE=ide émule un lecteur IDE pour la compatibilité. Le ballonnement mémoire est disponible mais documenté dans un fichier séparé.

Modes réseau

Le réseau en bridge est le mode par défaut et partage l'IP de l'hôte ; les ports sont publiés avec les mappages de ports Compose. En mode réseau utilisateur (par exemple avec Podman), les ports doivent aussi être listés dans USER_PORTS. Un réseau macvlan peut donner au conteneur sa propre adresse IP, auquel cas tous les ports sont exposés sans mappage ; le README avertit que l'hôte ne peut pas atteindre cette adresse à cause de la conception de macvlan, et suggère un second macvlan comme contournement. Définir DHCP sur Y, avec /dev/vhost-net et une règle de cgroup de périphériques, permet à la VM de demander une IP directement au routeur.

Accès aux périphériques et partage de fichiers

Les périphériques USB sont passés en mettant les identifiants vendeur et produit dans ARGUMENTS et en montant /dev/bus/usb. Les disques physiques ou partitions peuvent être mappés vers /disk1, /disk2, etc. Pour le partage de dossiers hôte, l'invité doit prendre en charge 9pfs ; un volume est monté vers /shared dans le conteneur et l'invité le monte avec 'mount -t 9p -o trans=virtio shared /mnt/example'. L'audio est désactivé par défaut ; définir AUDIO=Y et activer Audio sous Settings > Advanced dans le visualiseur diffuse l'audio vers le navigateur. Le README ne décrit pas comment vérifier ces fonctions au-delà de ces exemples.

Essai ciblé avec qemu

Compiler ou installer QEMU selon la plateforme, lancer une machine virtuelle avec une image de test et conserver la ligne de commande exacte. Vérifier le modèle de machine, le firmware, le réseau et les périphériques visibles dans le système invité. Comparer les options de `qemu-system-*` à la documentation de la cible, car le README ne fournit pas une garantie identique pour chaque accélérateur.

Conclusion éditoriale

Le README ne liste aucun utilisateur précis, benchmark ou résultat de performance au-delà de sa liste de fonctionnalités. Il renvoie vers des dépôts séparés pour Windows, macOS, ARM64 et Proxmox, et vers docs/environment.md pour l'ensemble des réglages. Ce dépôt fournit un wrapper léger autour de QEMU qui rend une machine virtuelle accessible via un navigateur ; tout le reste dépend du support KVM de l'hôte et des pilotes de l'invité.

Sources officielles

  1. Official README
  2. Project repository
  3. Release notes
Notes de la communauté

Notes de la communauté