Snapshots were read straight out of the QEMU images by the scripting commands, which only worked while the VM was off and knew nothing beyond the tags in the image. Put a backend behind the operations instead. Which one is chosen depends on whether the VM is running, and each says what it can do in that state: - A running VM goes through the QEMU monitor, which saves and loads the whole machine along with the disks. - A VM that is off goes through qemu-img, which can only save and revert disk contents. Nothing may touch the images while QEMU has them open, so a snapshot of disks alone is left alone until the VM stops. Either way a snapshot spans every writable image, the UEFI variable store included, because QEMU refuses to load one that any of them is missing. A snapshot that some of them lack, such as one taken before a drive was added, is kept but cannot be restored, which is not the same as its state being gone: reverting only some of the drives would leave them at different points in time. Reclaiming space rebuilds an image without its snapshots, so it is refused while there are any. UTMSnapshotService sits above the backend and keeps the manifest and the stored state consistent: it marks entries whose state has disappeared when an operation fails, and the first time a VM is opened it adopts whatever snapshots are already in the images so that snapshots taken by other tools are not lost. Both wait until the VM is stopped, because a running QEMU lists the snapshots of every drive together, removable ones included. Suspending is folded into the same mechanism. A VM now suspends to a snapshot of its own rather than always the same name, so a suspended state can be kept as a snapshot without copying it, and restoring a snapshot makes the VM resume from it. The state is deleted once nothing refers to it, where it used to be left behind in the image. One that cannot be deleted right away stays listed in the manifest and is tried again the next time. Assisted-by: Claude:claude-fable-5-1 Assisted-by: Claude:claude-opus-5
UTM
It is possible to invent a single machine which can be used to compute any computable sequence.
-- Alan Turing, 1936
UTM is a full featured system emulator and virtual machine host for iOS and macOS. It is based off of QEMU. In short, it allows you to run Windows, Linux, and more on your Mac, iPhone, and iPad. More information at https://getutm.app/ and https://mac.getutm.app/
Features
- Full system emulation (MMU, devices, etc) using QEMU
- 30+ processors supported including x86_64, ARM64, and RISC-V
- VGA graphics mode using SPICE and QXL
- Text terminal mode
- USB devices
- JIT based acceleration using QEMU TCG
- Frontend designed from scratch for macOS 11 and iOS 11+ using the latest and greatest APIs
- Create, manage, run VMs directly from your device
Additional macOS Features
- Hardware accelerated virtualization using Hypervisor.framework and QEMU
- Boot macOS guests with Virtualization.framework on macOS 12+
UTM SE
UTM/QEMU requires dynamic code generation (JIT) for maximum performance. JIT on iOS devices require either a jailbroken device, or one of the various workarounds found for specific versions of iOS (see "Install" for more details).
UTM SE ("slow edition") uses a threaded interpreter which performs better than a traditional interpreter but still slower than JIT. This technique is similar to what iSH does for dynamic execution. As a result, UTM SE does not require jailbreaking or any JIT workarounds and can be sideloaded as a regular app.
To optimize for size and build times, only the following architectures are included in UTM SE: ARM, PPC, RISC-V, and x86 (all with both 32-bit and 64-bit variants).
Install
UTM (SE) for iOS: https://getutm.app/install/
UTM is also available for macOS: https://mac.getutm.app/
Development
macOS Development
iOS Development
Related
- iSH: emulates a usermode Linux terminal interface for running x86 Linux applications on iOS
- a-shell: packages common Unix commands and utilities built natively for iOS and accessible through a terminal interface
License
UTM is distributed under the permissive Apache 2.0 license. However, it uses several (L)GPL components. Most are dynamically linked but the gstreamer plugins are statically linked and parts of the code are taken from qemu. Please be aware of this if you intend on redistributing this application.
Some icons made by Freepik from www.flaticon.com.
Additionally, UTM frontend depends on the following MIT/BSD License components:
Continuous integration hosting is provided by MacStadium


