Dans des install parties on à déjà été ammené à installer des VMs sous Windows ou MacOS. En général c'est quand même à déconseiller par rapport à une installation plus classique ou à un dual-boot car c'est beaucoup plus compliqué et niveau liberté et facilité d'usage c'est plus compliqué aussi.

Sous GNU/Linux ça reste super simple à faire. Il y'a pas mal d'applications pour ça comme virt-manager ou gnome-boxes. Voir vm-gnu-linux pour les VM GNU/Linux sous GNU/Linux.

Ça peut servir à mettre QEMU facilement à jour.

Il y'a des packages managers libres avec des pratiques assez correctes (normalement la plus part des logiciels packagé sont libres) comme Cygwin ou MSYS2 mais j'ai pas pu tester car ça fait plus de release 32bit et la tablette Windows Parinux est 32bit et j'ai pas de Windows du tout nulle part. Pour chocolatery ça à l'air d'avoir tout et n'importe quoi et d'utiliser les installeurs standards au lieu de fournir des vrais paquets.

Il y'a des packages managers comme brew qui sont disponible, parreil avec la plus part des applications qui sont libres. Par contre faut sans doute bidouiller avec MacOS récent pour lancer les applications qu'on veut. J'ai du aider quelqu'un à faire ça et on est allé sur le site d'apple pour trouver comment lancer un terminal, et ensuite on à suivi les instructions pour désactiver ce qui faut pour lancer ce qu'on veut.

QEMU est disponible pour Windows en 32 et 64bit. Avec ça il faut aussi installer un driver pour l'acceleration matérielle et un frontend (car la ligne de commande windows c'est pas terrible).

Drivers pour l'acceleration (remplace KVM sous GNU/Linux):

• WHPX: Supporté et conseillé par la documentation QEMU. Demande Windows 10 ou plus et assez peu de support matériel (vt-x+EPT+unrestricted guest/SVN, EPT, pas besoin d'iommu etc). Il y'a des instructions d'installation dans un tutoriel appelé Configure hardware acceleration for the Android Emulator. A ne pas confondre avec HyperV qui demande beaucoup plus de resources.

• HAXM: Plus maintenu mais encore disponible. Il faut installer HAXM d'abord puis qemu et redémarrer et ensuite installer QTEmu ou un autre frontend. Le support HAXM à été enlevé dans QEMU 8.2 (la dernière version de QEMU).

• AEHD (Android Emulator Hypervisor Driver): Est utilisé par l'emulateur Android. Je sait pas si on peut utiliser ça facilement avec un QEMU standard.

Frontends:

• EmuGUI: Le Projet à des release récentes (2024) mais par contre j'ai pas pu tester (j'ai pas Windows et la tablette Windows de Parinux n'a que Windows 32bit et ce projet ne fait pas de release 32bit).
• QTEmu: j'ai pu tester que des versions anciennes 32bit, les versions plus récentes sont bien mieux selon les vidéos qu'on trouve sur Internet. Les versions récentes supportent HAXM. Ça doit être possible d'utiliser ce qu'on veut comme aceleration quand même avec la version ancienne car on peut aussi passer des arguments à QEMU.

Selon https://libvirt.org/windows.html libvirt ne marche que comme client sous windows et n'est pas super testé ⇒ Inutile de conseiller ça.

Accélération matériel

• HVF: Intégré à MacOS ⇒ Rien à installer / configurer.

Frontend:

• UTM: Fonctionne aussi sur MacOS ARM, à l'air d'être la référence pour MacOS.

• x86box: Fonctionne aussi sur MacOS ARM.

Selon Debian, et Parabola, Virtualbox à des sérieux soucis de liberté. Le problème majeur est que le BIOS fournis avec Virtualbox est considéré pas libre en pratique car il dépend d'un compilateur pas libre:

• Le paquet Debian virtualbox est dans contrib. Si on télécharge l'archive pour debian/ on à l'info suivante dans le fichier copyright: “This package is not part of the Debian operating system.

It is in the “contrib” area of the Debian archive because it requires a non-free compiler (Open Watcom) to build the BIOS. Upstream provides pre-built BIOS images which is used instead.”

• Parabola est du même avis: “contains BIOS which needs a nonfree compiler to build from source (OpenWatcom compiler), [problème moin important] has nonfree user manual and [trucs spécifiques à parabola].” (https://git.parabola.nu/blacklist.git/tree/blacklist.txt).

Du coup en pratique les gens du libre ont tendance à utiliser des solutions à base de QEMU à la place au moins sous GNU/Linux (virt-manager, gnome-box, etc). Sous Windows et MacOS QEMU marche aussi avec un GUI adapté.

Après si la personne à déjà virtualbox on peut quand même installer des VM libres dedans, mais faut faire attention à ce qu'on rajoute dans la VM pour bien l'intégrer:

• virtualbox-ext-pack: Pas libre (interdiction d'usage commercial, etc).
• virtualbox-guest-additions-iso: Pas libre (interdiction d'usage commercial, etc).
• virtualbox-guest-utils, virtualbox-guest-x11 ont l'air libre: ils sont basés sur le paquet virtualbox qui contient un BIOS non libre, mais j'immagine que les VM n'en ont pas besoin à l'intérieur de la VM (c'est normalement fournit par virtualbox lui même).

A noter que selon Wikipedia, VirtualBox ne supporte que x86_64 (donc ça marche pas sur un ordinateur ARM de chez Apple par exemple).

TODO: trouver les pré-requis.

Pour booter une VM ARM sous UTM on devrait normalement avoir de l'UEFI[1]. Dans le cas contraire c'est possible de fournir un 'BIOS' comme u-boot-qemu-arm64 et booter avec ça mais la fonction risque d'être enlevé dans le futur (voir Image Type dans le manuel de UTM). Le reste (boot de kernel direct, etc) n'est vraiment pas pratique car le kenrel est dans l'image et il faut sans doute le copier en dehors de l'image.

Sinon sur les Mac ARM, les pages tables font 16K. Il y'a moyen de faire tourner des applications avec 4k mais ça risque d'être super lent. Certaines applications risquent aussi de ne pas marcher si les versions sont anciennes du à un manque de support pour les page tables qui font 16k. Voir la documentation de Asahi pour plus de détails.

Du coup il faut sans doute installer un kernel 16k:

• Debian: linux-image-arm64-16k (bookworm-backports)
• Fedora: kernel-16k (référence).

Références:

[1]En greppant dans le code de UTM on à ça: “Configuration/UTMQemuConfiguration+Arguments.swift: let bios = resourceURL.appendingPathComponent(“edk2-\(system.architecture.rawValue)\(secure)-\(code).fd”) Configuration/UTMQemuConfigurationQEMU.swift: templateVarsURL = resourceURL.appendingPathComponent(“edk2-arm-vars.fd”) Configuration/UTMQemuConfigurationQEMU.swift: templateVarsURL = resourceURL.appendingPathComponent(“edk2-i386-vars.fd”)” dans le code source de UTM Du coup on devrait avoir UEFI même sous ARM.

En plus de la license du wiki (http://creativecommons.org/licenses/by-sa/2.0/fr/) Ces instructions sont aussi disponibles sous les licenses suivantes:

• https://creativecommons.org/licenses/by-sa/3.0/
• https://creativecommons.org/licenses/by-sa/4.0/