VM Window MAC

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 gnu-linux pour les VM GNU/Linux sous GNU/Linux.

QEMU est libre et est disponible pour GNU/Linux, MacOS et Windows (y compris en 32bit).

Sous Windows il faut aussi installer un driver pour l'acceleration matérielle, et sous MacOS et GNU/Linux l'acceleration matérielle est déjà intégrée dans le système d'exploitation. C'est KVM sous GNU/Linux et HVF sous MacOS.

Pour Windows, les drivers suivants sont disponible (à installer):

• 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.

Il y a des interfaces graphiques diverses pour GNU/Linux, MacOS et Windows. Sous Windows et MacOS les interfaces gaphiques pour QEMU intègrent souvent QEMU dedans, donc en général on à pas besoin d'installer QEMU séparément.

Sous GNU/Linux en général c'est la distribution qui gère tout ça, donc la aussi on peut en général juste installer l'interface graphique.

Au niveau des interfaces graphiques qui marchent sur plusieurs système d'exploitations:

• Interfaces graphiques de libvirt (virt-manager, gnome-boxes, virt-viewer, etc):
  • Selon https://libvirt.org/windows.html libvirt ne marche que comme client sous windows donc c'est pas très utile.
  • Selon https://libvirt.org/macos.html libvirt marche bien sous MacOS. Brew.sh à virt-manager. Derrière ça utilise QEMU et HVF.
• x86box: Fonctionne aussi sur Windows, MacOS (y compris ARM) et GNU/Linux.
• QTEmu: Ça marchait bien sous GNU/Linux et Windows, mais ça n'a pas l'air d'être disponible sous MacOS. Ça n'est plus dans les distributions GNU/Linux récentes. Sous Windows, 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.
• EmuGUI: Ça tourne sous GNU/Linux et Windows. A noter que ce projet ne fait pas de release 32bit).

Les interfaces graphiques suivantes fonctionnent sous MacOS uniquement:

• UTM: Fonctionne aussi sur MacOS ARM, à l'air d'être la référence pour MacOS. Comme gnome-boxes on peut selectioner une distribution et UTM se débrouille. Ça à été testé lors d'une install party à Décartes: Une fois que l'on avait aidé une personne étudiante à installer ça, la personne à pu montrer comment faire aux autres personnes étudiantes et on avait plus à s'en occuper et donc on pouvait aider les personnes avec des cas plus compliqués.

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).

WSL2 ne marche que sur des Windows récents en 64bit. Il faudrait se renseigner sur combien de resources ça prend.

Si on télécharge l'iso de Debian sur le site de Debian (le bouton “Download” sur https://www.debian.org uniquement, pas une netinstall, etc), ça sait installer Debian automatiquement et VirtualBox permet de configurer le mot de passe, etc.

Du coup il ne faut pas utiliser VirtualBox si on veut avoir exactement ce que fournit Debian.

Par contre si on utilise l'ISO de Debian (le bouton “Download” sur https://www.debian.org uniquement, pas une netinstall, etc), ça peut accélérer et simplifier énormément l'installation.

Pour booter une VM ARM sous UTM on devrait normalement avoir de l'UEFI[1]. J'ai pas regardé avec les autres interfaces graphiques de QEMU.

Avec UTM c'est aussi 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/