Skip to content

Project Ideas

Jump to bottom
osy edited this page Jan 20, 2026 · 1 revision

GUI for VM snapshots

Effort: ~90 hours

Difficulty: Medium

Skillset: SwiftUI, UX/UI Design

Issue: https://github.com/utmapp/UTM/issues/5484

QEMU already has support for snapshots but UTM does not have an interface to expose this. We have qemu-img commands that can query and manipulate snapshots. We also have QEMU monitor commands to create live snapshots and restore them. The main challenge is to create and test an initiative UI for interfacing with snapshots. We can take inspiration from other VM software, but ultimately, the interface should be designed around the capabilities we already have with QEMU.

Breakdown of tasks:

  • GUI for snapshot viewing and management. I've taken a crack at this and am looking at splitting the details view into tabs and a new snapshot tab with a list of snapshots. But due to how unstable SwiftUI is on older macOS versions and iOS versions, it's been a lot of work just playing around with something that works on every supported version
  • Backend for managing snapshots via qemu-img. The basics are there: output json parsing, etc but we currently only parse image size so to expand it to support parsing snapshot info etc will be work
  • Screenshot management. QEMU doesn't take a screenshot but for usability it would be good to have one. We have all the code for taking screenshots already but some additional consideration: how do we prevent "orphaning" screenshot images from snapshots that fail to be created (ie process crash)? What do we do if the user later disables screenshots for privacy reasons? Not difficult technical issues but just a lot of things to think through.
  • iOS: we like to have feature parity with iOS version as much as possible. Currently, we don't support running qemu-img on iOS because we can't launch a new process and running it in the same process is broken (this is why you can't resize images on iOS). However in iOS 26, apple added support for running extensions in a new process and I believe this can be adapted to run qemu-img. But that requires a lot of re-architecture on the iOS side. This isn't required to work for launching the feature on macOS but it is good to have at least the UI stuff working on both platforms because of shared code.

Test infrastructure

Effort: ~90 hours

Difficulty: Medium

Skillset: SwiftUI, Swift, Xcode

Issue: https://github.com/utmapp/UTM/issues/2565

We currently don't have any test infrastructure. Time and time again, we've pushed releases that break something fundamental. The main challenge is that UTM is a complex GUI software so whatever test suite we develop has to handle a lot of automated GUI testing. This is also a good project to understand the codebase.

Breakdown of tasks:

  • Define the type of tests we want to run. This should be motivated with a discussion of bugs we had to deal with in the past (TBD document this list).
  • Development of the infrastructure for tests. This should take the majority of the time.
  • Development of the test themselves. This should be done in parallel with the previous task.
  • Integration with GitHub Actions for CI/CD.

Direct3D passthrough

Effort: ~350 hours

Difficulty: Hard

Skillset: DirectX, Graphics, C, Win32, WDK

Issue: TBD

Linux VMs have OpenGL and Vulkan passthrough for graphics acceleration. Currently, we don't have any graphics acceleration for Windows. There is some work on bringing OpenGL passthrough through VirGL but modern Windows graphics is done through D3D. One path could be to bring Vulkan passthrough to Windows and use DXVK and VKD3D but current Vulkan support for macOS (MoltenVK/KosmicKrisp) doesn't support running DXVK/VKD3D without out-of-tree patches that are not maintained mainline. Additionally, we would have to go D3D -> Vulkan -> Metal which introduces latency and reduces the supported feature set to whatever is supported by all three. On macOS we have D3DMetal and DXMT both of which can go directly from Direct3D to Metal. However, there is currently no way in QEMU to do passthrough of D3D to the host. The challenge would be to develop this feature.

Breakdown of tasks:

  • Define the serialization and transfer protocol for D3D commands. We can use gfxreconstruct as a point of reference (it serializes D3D draw commands for reply). To be compatible with other backends, we should use virglrenderer as the transfer protocol. We can use the blob feature of VirtIO-GPU and do something similar to Venus.
  • Implement the Windows driver for the guest
  • Implement the host renderer

Clone this wiki locally