Show HN: QEMU front end for M1 and Intel Macs (opens in new tab)

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.

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.

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.

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.

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.

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