--- title: Running Intel Binaries in Linux VMs framework: virtualization role: article role_heading: Article path: virtualization/running-intel-binaries-in-linux-vms --- # Running Intel Binaries in Linux VMs Run x86_64 Linux binaries under ARM Linux on Apple silicon. ## Overview Overview In macOS 13 and later on Mac computers with Apple silicon chips, the Virtualization framework supports apps using Intel binary translation in ARM Linux virtual machines (VMs). Until macOS 26, this capability was part of Rosetta, which allows apps built for Intel-based Mac computers to run seamlessly on Apple silicon. macOS 27 directly integrates support for Intel binary translation, without needing to install Rosetta. If your app has a minimum deployment target of macOS 27, continue with Create the Directory Share. note: The Virtualization framework doesn’t support the bootstrapping or installation of Intel Linux distributions on Mac computers with Apple silicon. Instead, it provides support for Intel apps that run in an ARM Linux distribution. Test for Rosetta on macOS 26 and earlier note: Starting in macOS 27, support for Intel binary translation for Linux apps is included in macOS. Testing for availability starting in macOS 27 always returns VZLinuxRosettaAvailability.installed and installRosetta(completionHandler:) always returns immediately. Before trying to install, run, or activate Rosetta, your app should check to ensure that the capability is available in the version of macOS running on the host computer. The availability class method returns a value from the VZLinuxRosettaAvailability enumeration that describes whether the current host supports Rosetta or if the capability is already installed on the host Mac. The example below shows the process for checking for Rosetta availability: Install Rosetta on macOS 26 and earlier In macOS 26 and earlier, you need to install Rosetta to allow apps built for Intel-based Mac computers to run on Apple silicon. Installing Rosetta is a one-time process per computer that requires someone to grant permission for the system to install Rosetta. If someone has already installed Rosetta, the system activates it for use under the Virtualization framework; if Rosetta isn’t installed, the framework downloads the installer from the network and performs the installation. The installer interactively prompts a person for authorization, and your app needs to handle any of the possible error conditions that could occur during the authorization, download, and installation process. The example below shows how to start the installation: Create the Directory Share With Intel binary translation support enabled, your app needs to configure an appropriate directory share in the Linux guest to enable translation capabilities. The shared directory must have a tag that uniquely identifies the share and that you validate using validateTag(_:) to ensure it conforms to the length and format for file system tags: Mount the shared directory and register Rosetta In order to use Intel binary translation in the Linux guest, a person must mount the Rosetta share in the guest VM and install Rosetta as the application the system uses to run x86_64 binaries using the following process: important: The remaining steps required to activate Intel binary translation in a Linux guest aren’t commands that your app can execute or that you can script from inside your application to a Linux VM; someone must perform them either interactively or as part of a script while logged in to the Linux guest. You must communicate these requirements to someone using your app. Install the update-binfmts command, if necessary. The command is part of the binfmt-support package in most Linux distributions; installation methods vary by distribution. Additionally, in order to run this command, someone must be able to use the sudo command, which requires adding their username to the system’s /etc/sudoers file. Create a directory as a mount point. Mount the VirtioFS file system tag to the mount point. This is the file system tag the app uses to identify the share and must be the same as the tag someone specifies on the command line demonstrated here. Check if the mounted directory has the Rosetta runtime. You should see rosetta in the mounted directory. Register the Rosetta runtime binary as the handler for x86_64 ELF format executable files using the update-binfmts command. The magic parameter describes the first 20 bytes of the ELF header for x86_64 binaries. The Linux kernel performs a bitwise logical AND with the first 20 bytes of a binary a user attempts to run with the mask value. If it matches the magic value, the kernel uses the registered handler as the interpreter for that binary. If the system can’t find a handler for the specified binary, it reports an error. The example below lists the commands, with the exception of the update-binfmts command installation, required to enable Intel binary translation in the Linux guest: important: When using Rosetta in macOS 13, set the preserve option to no. % mkdir /tmp/mountpoint % sudo mount -t virtiofs EXAMPLE_TAG /tmp/mountpoint % ls /tmp/mountpoint rosetta % sudo /usr/sbin/update-binfmts --install rosetta /tmp/mountpoint/rosetta \ --magic "\x7fELF\x02\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x3e\x00" \ --mask "\xff\xff\xff\xff\xff\xfe\xfe\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff" \ --credentials yes --preserve yes --fix-binary yes Ensure Shared Libraries are Available for Dynamically Linked Apps Rosetta can run statically linked x86_64 binaries without additional configuration. Binaries that are dynamically linked and that depend on shared libraries require the installation of the shared libraries, or library hierarchies, in the Linux guest in paths that are accessible to both the user account and to Rosetta. Configure Rosetta’s ahead of time (AOT) caching options In macOS 14 and later, Rosetta supports options that allow you control the ahead of time (AOT) cache characteristics; this can improve the performance of some X86 workloads. There are two modes of operation for AOT caching: The first is communication using a Unix Domain Socket where the Virtualization framework shares a file that represents the socket between the Rosetta daemon and Rosetta runtime through a symlink or bind-mount. The second is communication through an abstract socket where the framework defines a shared name rather than a shared file.  You enable these options after you create the Rosetta directory share by setting one of the VZLinuxRosettaDirectoryShare.CachingOptions using setCachingOptions(_:). This example shows how to configure Rosetta’s caching options in a new virtual machine configuration using a Unix Domain Socket though a shared, named file: The following example shows how to configure Rosetta’s caching options in a new virtual machine configuration using an abstract socket: ## See Also ### Virtual machine setup - [Running macOS in a virtual machine on Apple silicon](virtualization/running-macos-in-a-virtual-machine-on-apple-silicon.md) - [Running Linux in a Virtual Machine](virtualization/running-linux-in-a-virtual-machine.md) - [Running GUI Linux in a virtual machine on a Mac](virtualization/running-gui-linux-in-a-virtual-machine-on-a-mac.md) - [Installing macOS on a Virtual Machine](virtualization/installing-macos-on-a-virtual-machine.md) - [Creating and Running a Linux Virtual Machine](virtualization/creating-and-running-a-linux-virtual-machine.md) - [Virtualize macOS on a Mac](virtualization/virtualize-macos-on-a-mac.md) - [Virtualize Linux on a Mac](virtualization/virtualize-linux-on-a-mac.md) - [Accelerating the performance of Rosetta](virtualization/accelerating-the-performance-of-rosetta.md)