Show HN: QEMU front end for M1 and Intel Macs
mac.getutm.app
mac.getutm.app
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 :-)
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.
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.
https://labgopher.com/servers/Dell_R720/
Granted it's not 64cores, but still fast.
In this case it really is more than thousands of times more powerful.
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.
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
Probably similar reasons to what you mean by not having all code committed and pushed.
I wasn't aware of that setup you linked. I'll give that a go, thanks!
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.
[1]: https://lore.kernel.org/qemu-devel/20210126012457.39046-1-j@...
[2]: https://lore.kernel.org/qemu-devel/161259505296.24527.772997...
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
>>>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 voilà, 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.
A "true" type-2 hypervisor does not require any modification to the host kernel; at max it ships with a kernel module or two to help implementing things such as custom networking or to get a speed boost kernel side. For instance, it's trivial to share USBs with a guest on the fly with VirtualBox, because the VM is basically a process running on the host, so it can just tap into the USB stack and expose the device to the VM. This is not so simple with KVM.
And it shows, the UI is beautiful. Will try this out.
Wonder if this also helps developing for x86 Docker too (which is a major pain point on M1 Mac).
And, lovely work on the UI!
I will totally pay for this. Tired of paying yearly subscriptions to Parallels Desktop Lite which is another frontend to the OS hypervisor.
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.
https://stackoverflow.com/questions/59636198/how-to-compile-...
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.
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.
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.
Is it currently possible to have snapshots, like in VirtualBox, for instance?
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.
I am willing to buy. Just wondering what the author's plans are.
There was also a lot of speculation that Apple would quash booting other OSes, and maybe that got into the mix?
FWIW I’m a lifelong Apple user and even if I had the budget I’d hold off a year on ARM Macs, because I’ve learned to avoid first revision models in general.
1. The developer preview systems didn't support it, but that was because they used the older A12X chip. Lots of people spread that on social media as this not working on ARM at all.
2. Docker for Mac did not have ARM support at launch. Docker does have full ARM support so this was just a function of needing time to develop the desktop app (and not having access to the M1 hardware much ahead of anyone else) but some people panicked and portrayed this as something which would require a huge amount of work. There's a preview release out now: https://docs.docker.com/docker-for-mac/apple-m1/
There is no hardware assisted virtualization for x86 on ARM.
$ nm /Applications/UTM.app/Contents/Frameworks/libqemu-aarch64-softmmu.utm.dylib | grep -i hv_
U _hv_vcpu_create
U _hv_vcpu_destroy
U _hv_vcpu_get_reg
U _hv_vcpu_get_sys_reg
U _hv_vcpu_run
U _hv_vcpu_set_pending_interrupt
U _hv_vcpu_set_reg
U _hv_vcpu_set_sys_reg
U _hv_vcpu_set_vtimer_mask
U _hv_vcpus_exit
U _hv_vm_create
U _hv_vm_map
U _hv_vm_protect
U _hv_vm_unmap
https://github.com/utmapp/qemu/tree/apple-siliconhttps://developer.apple.com/documentation/hypervisor/apple_s...
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.
Oh well.
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