Un hyperviseur Apple avec des capacités supplémentaires uniques

Festival FOSS du vendredi UTM est un hyperviseur pratique pour les Mac et les fondleslabs Apple, mais c’est bien plus que cela. Il possède des compétences très particulières. Nous en sommes assez séduits.

UTM est un hyperviseur de bureau pour le kit Apple – notamment pour les Mac avec macOS 11 ou version ultérieure, mais il prend également en charge certains appareils iOS. (Malheureusement, Le Reg FOSS Desk n’a aucun nouveau ou assez puissant pour essayer cela.) Il prend en charge les Mac x86-64 et Apple Silicon, mais il peut faire plus que la plupart des autres hyperviseurs. À en juger par la citation d’Alan Turing sur sa page Github, nous pensons que le nom signifie Universal Turing Machine.

Entre autres choses, UTM peut servir d’interface à l’hyperviseur intégré d’Apple, une fonctionnalité de macOS 10.10 ou version ultérieure, appelée simplement Hyperviseur. À lui seul, l’hyperviseur Apple offre des fonctionnalités utiles : par exemple, il permet aux machines virtuelles Linux d’appeler Rosetta 2 pour une traduction très rapide de x86-64 vers Arm64. Cependant, UTM prend également en charge d’autres formes de virtualisation.

Il existe bien sûr déjà un choix d’hyperviseurs de bureau pour Mac : VMware Fusion, Parallels Desktop et bien sûr le multiplateforme VirtualBox. La plupart sont également disponibles dans des versions natives pour les Mac Apple Silicon, mais comme pour tout hyperviseur standard, ils exécutent des machines virtuelles du même type de processeur que la machine hôte sous-jacente. Ainsi, par exemple, la base de connaissances de Parallels explique soigneusement qu’il ne peut exécuter que Windows pour bras sur les Mac Apple Silicon.

Il s’agit d’un comportement standard pour un hyperviseur : ils virtualisent le matériel sous-jacent, de sorte que les machines virtuelles disposent du même type de processeur que l’hôte. Ainsi, si vous exécutez un hyperviseur x86-64 sur x86-64, il ne peut exécuter que des invités x86-64, et si vous exécutez un hyperviseur Arm sur Arm, il ne peut exécuter que des invités Arm.

C’est là que l’UTM est différent. En plus de l’hyperviseur Apple, il prend également en charge le QEMU open source du spécialiste français de la programmation bas niveau Fabrice Bellard.

QEMU est un outil inhabituel et complexe, capable de fonctionner de plusieurs manières différentes, ce qui signifie qu’il est souvent mal compris. QEMU est capable d’agir comme un émulateur de système complet, exécutant le logiciel d’une famille de processeurs sur un processeur totalement différent. Pour ce faire, il dispose d’outils pour créer et gérer des disques durs émulés, des cartes graphiques et réseau, etc. : tout le matériel virtuel dont le système émulé a besoin pour fonctionner.

Cependant, ce qui prête à confusion, c’est que depuis la version 2.6.20 de 2007, le noyau Linux possède son propre hyperviseur KVM intégré, qui à son tour utilise les fonctionnalités de virtualisation matérielle de toutes les puces Intel et AMD modernes, comme le Rég Bureau FOSS couvert en détail en 2011. Mais tous Ce que KVM peut faire, c’est communiquer avec les fonctionnalités intégrées du processeur qui démarrent et arrêtent les instances virtualisées. KVM à lui seul n’a pas la capacité de définir des lecteurs de disque virtuel, des adaptateurs graphiques, ou quoi que ce soit de ce genre.

Que C’est là que QEMU entre en jeu. Il est largement utilisé dans la plupart des distributions Linux pour fournir cet échafaudage frontal supplémentaire : pour créer, fournir et gérer tout le matériel supplémentaire pour les machines virtuelles. Essentiellement, le noyau Linux fournit le processeur et QEMU s’occupe du reste. Dans ce mode, QEMU n’émule pas du tout le processeur : le système d’exploitation le fournit, ce qui signifie que le code invité s’exécute à une vitesse proche de la vitesse native sur le processeur sous-jacent réel. Ce que l’on sait moins, c’est qu’il peut faire la même chose sur macOS.

C’est de là que vient l’incompréhension de QEMU. Ça peut marcher les deux en tant qu’émulateur de système complet et en tant qu’hyperviseur de type 2 à l’aide d’un noyau et d’un processeur qui fournissent les fonctionnalités pertinentes.

UTM entoure une interface graphique conviviale autour de deux hyperviseurs différents, l’un d’eux étant capable de fonctionner dans deux modes différents. Il peut utiliser directement l’hyperviseur Apple, virtualisant votre processeur Intel ou Apple Silicon sous-jacent, mais en plus de cela, il peut également utiliser QEMU, soit comme hyperviseur pour une virtualisation à vitesse native, mais aussi en mode émulation.

UTM exécutant à la fois MacOS classique et Solaris sur un MacBook Air M1 sous Sonoma (cliquez pour agrandir)

Cela signifie que UTM peut exécuter un invité x86 sur Apple Silicon ou un invité Arm64 sur un Mac Intel. Et il ne se limite pas aux Mac Arm et x86 : il peut également exécuter une machine virtuelle PowerPC ou SPARC sur les Mac Intel et Arm64.

Pour tester cela, nous avons téléchargé un fichier ISO d’installation universelle MacOS 9.2.2 à partir de MacOS9Lives, choisi une machine virtuelle PowerPC et quelques minutes plus tard, nous avons été profondément impressionnés d’exécuter Classic sous macOS Ventura. Nous avons également installé l’édition Arm64 de Debian 12 sur un iMac Core i7.

Si vous ne souhaitez pas configurer votre propre VM, UTM propose une galerie d’images d’invités prédéfinies et, lors des tests, nous avons exécuté avec succès le Classic MacOS 9.2.1 natif PowerPC sur les Mac M1 et Core i7. Nous avons également installé la version SPARC de Sun Solaris 9 sur les deux machines.

L’émulation est loin d’être aussi rapide que la véritable virtualisation : la VM SPARC n’était pas vraiment rapide, mais elle est utilisable. Cependant, même un Core i7 vieux de huit ans est nettement plus rapide que les Mac les plus rapides capables de démarrer MacOS 9 de manière native, et MacOS 9 ne nécessite que 40 Mo de RAM et fonctionne bien sur les Mac G3 à 233 MHz : ce n’est pas un système d’exploitation exigeant selon les normes du 21e siècle. .

Ce n’est pas la même chose que le mode classique sous Mac OS X 10.0 à 10.4 : il y a peu d’intégration entre le système d’exploitation hôte et invité, et vous devez déterminer par vous-même comment déplacer des fichiers entre eux. Malgré cela, nous avons été très impressionnés par la facilité avec laquelle UTM permet de réaliser cet exploit d’émulation.

Nous avons également testé la version bêta de Fedora 39 en UTM, et elle a fonctionné plus facilement que sous VirtualBox – sans doute parce que l’hyperviseur natif de Fedora, GNOME Boxes, utilise les mêmes outils QEMU sous-jacents.

Même si vous ne voulez pas de tous les éléments d’émulation, il s’agit d’un hyperviseur x86 sur x86 parfaitement utilisable, exécutant ici la dernière version bêta de Fedora (cliquez pour agrandir)

L’exécution de systèmes d’exploitation x86-64 entiers sur notre MacBook Air M1 était moins impressionnante : Rosetta 2 effectue la traduction application par application et ne peut pas aider à l’émulation complète du système. Les performances du système d’exploitation invité étaient un peu lentes, mais supportables : on pouvait le tolérer pour une utilisation modeste.

Cela a fortement rappelé à ce vautour l’utilisation de !PCEm d’Acorn [PDF] Logiciel d’émulateur PC sur l’ordinateur de bureau ARM d’origine, l’Acorn Archimedes, sous RISC OS à la fin des années 1980. Bien que vous préfériez toujours utiliser un logiciel natif s’il est disponible, il était très impressionnant qu’un ARM2 à 8 MHz ait la puissance brute nécessaire pour émuler complètement un PC x86 à une vitesse utilisable. Il était impressionnant qu’un ordinateur ARM puisse émuler un IBM de classe XT inférieur à 5 MHz compatible avec 640 Ko de RAM il y a 35 ans, et il est tout aussi impressionnant qu’il puisse émuler un PC multicœur 64 bits avec 4 Go de RAM aujourd’hui.

UTM est téléchargeable gratuitement sur Github, mais si vous l’obtenez sur le macOS App Store d’Apple, il coûte 9,99 $, ce qui contribue à financer le développement du programme. ®