[HN Gopher] Show HN: QEMU front end for M1 and Intel Macs
       ___________________________________________________________________
        
       Show HN: QEMU front end for M1 and Intel Macs
        
       Author : osy
       Score  : 381 points
       Date   : 2021-02-25 06:48 UTC (16 hours ago)
        
 (HTM) web link (mac.getutm.app)
 (TXT) w3m dump (mac.getutm.app)
        
       | kristiandupont wrote:
       | Hey, I need to thank you for this!
       | 
       | This is what I use to run QEMU on my M1 Air. I had a few bumps
       | setting it up but now it runs flawlessly. I SSH to it via VS Code
       | and basically I have a fully functional Linux dev environment
       | with MacOS as the UI, just the way I like it.
       | 
       | Honestly, I haven't been this excited about a new setup since
       | Moore's Law was in effect :-)
        
         | mav3rick wrote:
         | Just to confirm - This project has a UI over Qemu which in turn
         | uses this
         | https://developer.apple.com/documentation/virtualization
         | hypervisor API to create and manage VMs on a Mac ?
        
           | osy wrote:
           | It (QEMU) actually uses the older
           | https://developer.apple.com/documentation/hypervisor apis
           | which has lower level control. QEMU provides device emulation
           | and Hypervisor.framework provides access to CPU's
           | virtualization hardware. Virtualization.framework is the new
           | macOS 11 api that emulates the entire system but has much
           | worse device emulation support and also lacks framebuffer
           | emulation (I think)
        
             | mav3rick wrote:
             | Right, so the older API is akin to "/dev/kvm" and ioctls on
             | Linux ?
        
               | my123 wrote:
               | It's actually a bit lower level than KVM.
        
               | mav3rick wrote:
               | Basically a hook in the kernel ?
        
         | signorettif wrote:
         | Hey man, care to elaborate? Seems like what I am looking for.
         | How do you handle SSH'ing into the local VM? Are your files on
         | the VM or on Mac?
        
           | kristiandupont wrote:
           | Files are on the VM. SSH just goes through an exposed port.
           | Feel free to email me if you need help!
        
         | ryall wrote:
         | I do this except the Linux is on a separate box and the dev
         | envs are docker containers.
         | 
         | Decided to spend my money on decent, upgradeable hardware
         | instead of shelling out 5k for another MB Pro. My next MacBook
         | will probably be the most low-end I can get.
         | 
         | VSCode's remote/docker support is a godsend. Seems like we're
         | heading back to the dumb terminal paradigm.
        
           | txdv wrote:
           | Except that the terminal is thousands and thousands times
           | more powerful than the machine you connected to with the
           | terminal back in the days.
        
             | danlugo92 wrote:
             | Can't get that with AWS though? Some kind of spinup-able
             | VPS?
             | 
             | Like a normal VPS but you can get dat 64 cores + 64gb ram
             | only the day you need them and otherwise pay a low monthly
             | fee.
        
             | KMnO4 wrote:
             | I train ML models on my Macbook (Intel GPU) by SSHing into
             | a machine with a Tesla A100.
             | 
             | In this case it really is more than thousands of times more
             | powerful.
        
           | haffi112 wrote:
           | Do you recommend any tutorials online to get such a setup?
        
             | tnorthcutt wrote:
             | Wondering the same thing. I'd like to explore a setup like
             | this but trying to cobble it together myself without a good
             | guide is daunting.
        
             | ryall wrote:
             | I've been considering writing one myself, admittedly it's
             | not an easy road at first, and a step by step guide
             | would've helped a lot.
        
           | kristiandupont wrote:
           | I did this too and that is very pleasant as well. But the new
           | Air performs well and has no fan and the feeling is, quite
           | frankly, the same.
        
             | ryall wrote:
             | And the way you're doing it sounds like you avoid the
             | docker mount slowdown issue. Sounds like quite a good
             | solution
        
           | dmos62 wrote:
           | > the dumb terminal paradigm
           | 
           | Hehem. The paradigm you're referencing is letting you do what
           | you want to do (because it's a powerful paradigm). We need
           | more of that if anything.
        
           | cassianoleal wrote:
           | Do you have your projects cloned in the remote host?
           | 
           | I ask because I was excited about this prospect only to learn
           | that I could only use Remote: Containers if codebase and
           | container are on the same machine as the project workspace is
           | just volume-mounted in the container.
        
             | connor4312 wrote:
             | There are more options here. For example, you can attach to
             | fully remote containers:
             | https://code.visualstudio.com/docs/remote/containers-
             | advance... or just attach to existing local containers that
             | you can set up however you'd like.
        
               | cassianoleal wrote:
               | Yeah I have been using local containers and I really like
               | the workflow.
               | 
               | I wasn't aware of that setup you linked. I'll give that a
               | go, thanks!
        
             | ryall wrote:
             | Yeah I dusted off an old licence I had for resilio sync and
             | use that to sync with my local machine.
             | 
             | You can get around this by running git clone inside your
             | container as part of the startup process. But 1. It can add
             | quite a delay to starting a container depending on the size
             | of your codebase, and 2. Not all of my code is necessarily
             | committed and pushed.
             | 
             | For me, syncing works well but I can see how it would not
             | suit every use case
        
               | cassianoleal wrote:
               | Fair enough. I don't want to clone from within the
               | container because I like the idea of being able to nuke
               | it at any time and just start over from local code.
               | 
               | Probably similar reasons to what you mean by not having
               | all code committed and pushed.
        
             | [deleted]
        
         | sammorrowdrums wrote:
         | QEMU is amazing. I run Linux, ans being able to dockerize
         | Windows with it, and set up a selenium testing environment I
         | can run locally or on CI servers is genuinely mind-blowing.
         | Headless chrome, Firefox plus a windows in docker setup means
         | pretty great automated test coverage without relying on third
         | party infra.
        
       | mvniekerk wrote:
       | Wondering if there could be a Metal -> Vulkan -> Zink -> OpenGL
       | way of doing HW acceleration. Or Metal -> Vulkan -> DXVK -> D3D
       | for Windows. AFAIK VirtualBox used some of Wine's D3D code to do
       | D3D on Virtualbox.
        
         | osy wrote:
         | In theory virgil3d is the way to go as it has existing support
         | in QEMU but there hasn't been any work porting it to
         | macOS/Metal as of this post.
        
       | therealmarv wrote:
       | Oh very interesting. I only need Vagrant support and then I can
       | fully switch to M1 in the future. Looks like this could be the
       | successor for Virtualbox on Mac M1.
       | 
       | Wonder if this also helps developing for x86 Docker too (which is
       | a major pain point on M1 Mac).
        
       | eliaskg wrote:
       | Random question but when I tried to install Debian on this I got
       | an error that no cdrom drive was detected. Is there a workaround?
        
         | bni wrote:
         | Use the Debian netinst iso instead?
        
           | eliaskg wrote:
           | I used exactly that
        
             | mbreese wrote:
             | When the Debian install asks you what device to use, give
             | it /dev/sda or /dev/vda. For some reason /dev/cdrom wasn't
             | working for me either. I ended up switching the ISO's
             | device to virtio and tried /dev/vda and it worked.
             | 
             | The ISO was on /dev/vda and the target disk image was on
             | /dev/vdb. Just make sure you install the bootloader on the
             | disk image. Then when I removed the ISO, everything was
             | just fine.
        
       | qalmakka wrote:
       | This is a very nice frontend. Someone should definitely port it
       | or rewrite it for Linux. All the existing UIs are either ugly or
       | use libvirt, which is a nasty pile of hacks that has no place on
       | a desktop machine.
        
         | captn3m0 wrote:
         | Not sure what GNOME Boxes uses, but it looks good:
         | https://wiki.gnome.org/Apps/Boxes
        
           | sanxiyn wrote:
           | Boxes uses libvirt too. (It would be foolish not to.)
        
         | pm215 wrote:
         | libvirt has put a lot of time into figuring out how to run QEMU
         | in the most secure and performant way (specific low-privilege
         | user, seccomp, all the right options for virtio, etc, etc). If
         | you aren't using it then that's a lot of effort to reinvent,
         | and you probably missed something out.
        
           | lima wrote:
           | But they also hid it behind it layers of XML-laden
           | complexity. If you know exactly what you want, using QEMU
           | directly may be preferable.
        
             | orf wrote:
             | https://pypi.org/project/libvirt-python/
        
               | lima wrote:
               | That doesn't help one bit with the impedance mismatch
               | that you get when you want to do something that goes
               | against libvirt's abstraction layer.
        
           | qalmakka wrote:
           | libvirt wasted a lot of effort into abstracting everything
           | behind a ton of pointless hypervisor-agnostic cruft, only to
           | then deprecate basically every single backend except QEMU.
           | 
           | I have used libvirt for almost a decade before going back to
           | plain QEMU; I must say that using it from the CLI is an
           | herculean task, you often have to edit plain XML in order to
           | do whatever you want, and the cherry on top is that `virsh`is
           | a huge pile of cow dung that often drags you into a Sisyphean
           | fight against the aforementioned pointless abstractions - you
           | find yourself configuring "domains" and "virtual networks"
           | when you really only wanted to launch Windows to run Word.
           | 
           | When I had to run stuff on a big server which only does VM,
           | maybe with OpenStack and other orchestration systems on top,
           | libvirt was often _fine_. I still use it in those use cases
           | (I usually prefer Proxmox this day, though), it works fine, I
           | can connect to remote instances using SSH and Virt-Manager
           | and I like how it often just works.
           | 
           | My use case, 90% of the time, is that I just want to run a
           | damn Windows or FreeBSD VM on my workstation. I want to put
           | disk images wherever I want because my root FS is small
           | (often on ZVOLs, which are a big massive PITA to use with
           | libvirt) without having to read a million different websites
           | and man pages. I want it to work with my firewall
           | configuration, which often changes due to the fact I have to
           | do stuff with this machine, and I don't really care about 90%
           | of the features of libvirt - I just want to run Windows every
           | once in a while and I want my VMs to keep working without too
           | much effort.
           | 
           | Thus, I run plain QEMU with the following configuration,
           | which took me a solid 10 minutes to perfect:
           | 
           | - `nsbr0`, a bridge with a static IP configured using
           | systemd-network;
           | 
           | - `qemu-bridge-helper` set-up in order to attach taps to
           | nsbr0 automatically, using `-netdev bridge` (echo 'allow
           | nsbr0' > /etc/qemu/bridge.conf);
           | 
           | - IP forwarding set to 1 and `masquerade` in nft.conf;
           | 
           | - OVMF downloaded from my distribution's repos;
           | 
           | - `spicy` to attach to a running VM;
           | 
           | - a 30 line script that spawns QEMU in a tmux. If I want to
           | configure a new VM, I just copy paste this shell script and I
           | put it in a directory together with a copy of OVMF_VARS.fd
           | for the efivars.
           | 
           | Et voila, I get VMs that just work, without having to wage
           | any pointless battle against libvirt in order to get what I
           | want. This is basically just a way to run KVM VMs that does
           | not create a million firewall rules together with useless
           | network interfaces, and doesn't force me to configure
           | "storage pools" when the only thing I care about is running
           | 2, 3 VMs max on my machine.
           | 
           | There's a reason why VMWare sells both ESXi and VMWare
           | Workstation, and why people still love VirtualBox despite how
           | shitty it is.
           | 
           | It's because more often than not something designed to run on
           | servers is hardly be the best solution for a single user. The
           | same features that make libvirt interesting on servers make
           | it clumsy and overcomplicated on workstations, and the more I
           | use it the more I realize it's true.
        
             | marmaduke wrote:
             | I find VirtualBox a pretty good solution for a lot of
             | stuff. What's wrong with it?
        
               | qalmakka wrote:
               | It's a type-2 hypervisor, so its performance is often
               | quite worse than KVM. Also, its storage drivers are quite
               | wonky, so I/O is often choppy and underwhelming. It has
               | often a better desktop experience, though, except when
               | you run Linux with VirGL. Also, virtualbox cannot emulate
               | other platforms; for instance, I often run AArch64
               | operating systems in full emulation using QEMU on my
               | x86_64 workstation.
        
         | osy wrote:
         | Thanks but I think a port is virtually impossible as this was
         | designed in SwiftUI and depends extensively on Apple APIs.
         | GNOME Boxes is a good UI on Linux.
        
       | sirn wrote:
       | Also worth mentioning that UTM developers has been contribution
       | patches to QEMU to get TCG (code emulation layer) to work under
       | iOS / M1 Mac[1] as well (whereas I think TCG is still broken as
       | of latest QEMU release due to mprotect[2]). So huge, huge thanks
       | for this as well!
       | 
       | [1]: https://lore.kernel.org/qemu-
       | devel/20210126012457.39046-1-j@...
       | 
       | [2]: https://lore.kernel.org/qemu-
       | devel/161259505296.24527.772997...
        
         | sigjuice wrote:
         | There's a tiny patch mentioned in your second link that makes
         | TCG work again on M1 Macs
         | 
         | https://bugs.launchpad.net/qemu/+bug/1914849/comments/3
         | $ qemu-system-alpha -nographic       PCI: 00:00:0 class 0300 id
         | 1013:00b8       PCI:   region 0: 10000000       PCI:   region
         | 1: 12000000       PCI: 00:01:0 class 0200 id 8086:100e
         | PCI:   region 0: 12020000       PCI:   region 1: 0000c000
         | PCI: 00:02:0 class 0101 id 1095:0646       PCI:   region 0:
         | 0000c040       PCI:   region 1: 0000c048       PCI:   region 3:
         | 0000c04c       >>>
        
       | reichardt wrote:
       | Seems to support QXL graphics driver and SPICE? I ran into
       | problems compiling QEMU on macOS with the above mentioned. Did
       | you solve this?
       | 
       | https://stackoverflow.com/questions/59636198/how-to-compile-...
        
         | osy wrote:
         | Check out https://github.com/utmapp/UTM/tree/master/patches
        
       | AshleighBasil wrote:
       | I use Parallels. What is the benefit of QEMU compared to
       | Parallels?
        
       | Tepix wrote:
       | Nice page, very clean and straightforward, yet not too dull. Cool
       | project!
        
       | amelius wrote:
       | Nice for Apple users but how/when can I run Mac and iOS
       | applications on Linux?
        
         | pabs3 wrote:
         | Use this equivalent of Wine for macOS apps called Darling:
         | 
         | https://www.darlinghq.org/
        
         | dividedbyzero wrote:
         | AFAIK you can't, and there's no indication that will change.
         | You may be able to virtualize a whole macOS install, though
         | that's pretty difficult even on Apple hardware (source: I tried
         | several times, and didn't get it to work well)
        
           | wazzaps wrote:
           | https://github.com/foxlet/macOS-Simple-KVM works pretty well
           | for me (not for daily use though as it uses software
           | rendering, but fine for compiling/testing apps)
        
           | amelius wrote:
           | I think many open-source efforts are heading in the wrong
           | direction. Let Apple make sure our software runs on their
           | hardware, and let FOSS make sure that Apple software runs on
           | FOSS platforms. Not the other way around.
        
             | ngcc_hk wrote:
             | Dream on one can. But sorry mate reality bite.
        
         | lolive wrote:
         | Try this: https://github.com/myspaghetti/macos-virtualbox
        
           | lolive wrote:
           | Be careful, I think you need something like 50-60GB of free
           | space to run it. And the script does not check the free space
           | beforehand. After the script is run, I think the OS X VM will
           | occupy at least 25GB.
           | 
           | PS: the graphics performance is ok, but not great. I could
           | not manage to install the extension package of VirtualBox, so
           | may be if you can install it, then the graphics performance
           | of the virtualized OSX will improve.
        
       | Exuma wrote:
       | I thought virtualization doesn't work with M1? Like docker and
       | such... did something change?
        
         | stu2b50 wrote:
         | No, that was never the case. Even Docker is running, albeit
         | still in WIP status (https://docs.docker.com/docker-for-
         | mac/apple-m1/).
        
       | wolfhumble wrote:
       | Which parts of QEMU on M1 are hardware accelerated?
        
         | saagarjha wrote:
         | Emulation, which goes through a hypervisor. I don't believe
         | graphics are yet.
        
         | als0 wrote:
         | Technically the AArch64 instruction set and the memory system
         | are the only parts that are 'hardware accelerated'. QEMU
         | handles everything else in software.
        
         | notaplumber wrote:
         | Specifically arm64 guests, otherwise it's just QEMU's TCG.
        
       | wolfium3 wrote:
       | What does UTM stand for? Couldn't find it on google or in the
       | FAQ...
        
         | osy wrote:
         | https://en.wikipedia.org/wiki/Universal_Turing_machine
        
       | tpetry wrote:
       | The commercial virtualisation tools from Parallels and VMware
       | support creating macOS guests on a macOS host by making a clean
       | install, i guess from the macos recovery system/service?
       | 
       | Are you planning on macOS guests too? It's sometimes really nice
       | to test a macOS application on an absolutely clean macOS install
       | to ensure it's not dependent on any library on your macOS
       | development machine.
        
         | osy wrote:
         | macOS support isn't perfect in QEMU but there's been people who
         | got it working:
         | https://khronokernel.github.io/apple/silicon/2021/01/17/QEMU...
        
       | lukeh wrote:
       | Looks like it's built with SwiftUI too, nice!
        
       | proyb wrote:
       | Running UTM with Ubuntu Server 20.04 ARM64 ISO image, it prompt
       | UEFI and I couldn't install like it did work a few month ago.
        
       | m3nu wrote:
       | Looks good. How is the speed compared to vmware?
        
         | dastx wrote:
         | The underlying tech is QEMU, so probably equivalent or better.
        
         | sigjuice wrote:
         | It is infinitely faster than VMware on M1 Macs :)
        
       | willswire wrote:
       | From one dev to another, can't thank you enough! Just bought it
       | on the App Store to support you.
        
       | isodev wrote:
       | Just bought it on the app store, very nicely done!
        
       | cozzyd wrote:
       | Is this legal to deploy on the Mac app store? Not sure if the Mac
       | app store has the same license incompatibility issues as the iOS
       | app store.
        
         | stu2b50 wrote:
         | afaik there is nothing preventing this from being on the mac
         | app store.
         | 
         | The iPhone app store is so strict because they really want to
         | keep the platform locked down, with no possibility for 3rd
         | party app stores. Although even then there's weird exceptions -
         | Roblox seems to be allowed.
         | 
         | That cat is out of the bag on MacOS, though, and at least for
         | now it seems Apple is keeping it that way - iPadOS is going to
         | be their locked down work OS.
        
           | cozzyd wrote:
           | Well, it seems controversial, to say the least (unless qemu
           | and other GPL components are not actually bundled? I don't
           | know... I don't have a Mac):
           | 
           | https://apple.stackexchange.com/questions/6109/is-it-
           | possibl...
           | 
           | It's possible that those replies are out of date and the Mac
           | App Store TOS have changed.
        
       | Toutouxc wrote:
       | > UTM was created for macOS and only for Apple platforms
       | 
       | And it shows, the UI is beautiful. Will try this out.
        
       | pdimitar wrote:
       | The price isn't that big, I have to wonder if this product will
       | be supported for the next, say, 5 years?
       | 
       | I am willing to buy. Just wondering what the author's plans are.
        
         | osy wrote:
         | Please try out the free download and only purchase it if you
         | feel that you've already gotten value from it and would like to
         | support the project. There is no difference in the binary for
         | the free and paid version. It's really hard to promise anything
         | 5 years ahead as the intent is not to make money off of it.
        
           | pdimitar wrote:
           | I did not realize there was a free version. Thank you!
        
       | mikkelam wrote:
       | How is the x86 performance on say windows and linux?
        
         | osy wrote:
         | Do you mean the emulation performance on M1? In my experience
         | Windows XP is "usable" and Windows 7 feels like a 10 year old
         | desktop running with a spinning drive.
        
         | notaplumber wrote:
         | Linux arm64/Windows 10 ARM should be near native, minus
         | graphics acceleration. x86 will be about as slow as you would
         | expect with QEMU. Pretty slow.
         | 
         | There is no hardware assisted virtualization for x86 on ARM.
        
       | thrrck wrote:
       | Very nice! Any way to 'buy'/donate without giving 30% to Apple?
        
       | jzer0cool wrote:
       | Just a silly question here but what's the UTM acronym meaning?
       | 
       | I have been a QEMU user for over a decade now. Virtualization was
       | fun back then, but so slow forcing me to experiment with many.
       | All is so decent now.
        
       | kljsandjb wrote:
       | Well it is great in many ways, but today I downloaded it and
       | played a bit and found it hard to use compared with "directly
       | using qemu cli" or vmware fusion for Mac free edition, but I am
       | looking forward to its improvements in the future. Please do keep
       | the good work ;-) thanks!
        
       | [deleted]
        
       | webmobdev wrote:
       | Thank you for making this available for download from the website
       | too, and not making it app store exclusive. Do you have any plans
       | to support macOS Mojave? What is needed to add GPU support in the
       | future?
        
         | osy wrote:
         | GPU support will probably come from implementing virgil3d in
         | Metal.
        
         | saagarjha wrote:
         | Since it uses SwiftUI heavily, I doubt it.
        
       | unicornporn wrote:
       | This is insane. Best software find in a long time. An open-source
       | alternative to Fusion is very welcome for me.
       | 
       | And, lovely work on the UI!
        
       | tambourine_man wrote:
       | This is great, thank you.
       | 
       | Is it currently possible to have snapshots, like in VirtualBox,
       | for instance?
        
         | osy wrote:
         | Not yet but it's planned for the future but after other higher
         | priority features like USB, network bridging, and running from
         | other paths.
        
           | eyberg wrote:
           | What is the plan for network bridging? Tuntaposx isn't an
           | option anymore and Apple has plans to ban all kexts.
        
             | osy wrote:
             | https://developer.apple.com/documentation/vmnet
        
               | eyberg wrote:
               | interesting - thanks!
        
       | josteink wrote:
       | Saw UTM for iOS, got excited, only to find out it's not available
       | in the App Store, and I have no Mac to build it with.
       | 
       | Oh well.
        
         | _fzslm wrote:
         | You can sideload it without a jailbreak using AltStore:
         | https://getutm.app/install/
        
           | josteink wrote:
           | Thats interesting. But it seems like the AltStore requires
           | running a AltServer which is only available for Mac or
           | Windows. It would be great if they provided a Linux build
           | too.
           | 
           | It is kind of ironic though that I need to bring up a QEMU VM
           | to run the AltStore binary which lets me run QEMU on my phone
           | :D
        
       | chubs wrote:
       | Thanks for creating this, it looks fantastic, I just bought it! I
       | love that it's a nice layer over QEMU / Apple's Hypervisor, so i
       | know the performance will be reasonable. One bit of feedback you
       | might consider: Most of the VMs in your gallery are for ARM64,
       | and the x86 one is quite an old version of Ubuntu. Would you
       | consider making a couple more modern x86 versions? My requirement
       | is to have an x86 VM for deployments to Lambda, cross compiling
       | Rust using Docker on M1 simply doesn't work yet and I'm hoping
       | your app will do the trick :) Thanks!
        
         | groundthrower wrote:
         | I have the same requirement, but ended up building the final
         | bundles to lambda in the cloud instead. However I am quite
         | excited about the new container image support for lambda
         | meaning I guess you do not have to compile for musl anymore.
        
       | ulzeraj wrote:
       | Where have you been OP? I've been waiting for years.
       | 
       | I will totally pay for this. Tired of paying yearly subscriptions
       | to Parallels Desktop Lite which is another frontend to the OS
       | hypervisor.
        
       | bluedino wrote:
       | Any benchmarks?
        
       ___________________________________________________________________
       (page generated 2021-02-25 23:03 UTC)