Live data from Hacker News

macOS in QEMU in Docker

github.com

61–70 of 190 posts

Re: macOS in QEMU in Docker

#61
post #47

So this is pretty misleading. It's really a full system emulator (qemu) running inside Docker, using root privileges on the container that make the isolation very weak (--privileged). It also uses hardware assisted virtualization (KVM) which is not going to be available most of the time Docker is. You can think of the Docker platform itself as subset of the Linux platform. With many common features removed by default…

I think "docker" is an ambiguous term nowadays. Depending on your point of view, it could denote a container, or source control, or a sort of makefile. To me it is a reproducible recipe in 43 lines of Dockerfile text.

This thing is basically a bash script that runs the package manager of a distro pointing to the latest package feed; not even a specific stable version or anything like that.

It also depends on host kernel features such as KVM settings and hardware such as CPU (good luck on AMD) much more than whatever is packaged on the container.

This is about as "reproducible" as replaying my .bash_history on a different machine. I would bet that before the end of this year this script no longer works.

Re: macOS in QEMU in Docker

#62
post #42

Earlier quoted context omitted.

its using docker as an artifact delivery mechanism, not as an isolationism mechanism.

Honestly that's kind of yikes. That probably just adds extra complexity, and there are better ways to deliver VMs.

> there are better ways to deliver VMs

For the curious - what are they?

Re: macOS in QEMU in Docker

#63
post #16

It's hard to see what Docker is adding here since qemu is being run inside Docker. You could get almost identical functionality out of a bare VM image and not deal with the hassles of docker.

I know it's against the HN rules to complain, but this comment really feels so generic. Like every time a JS project is posted, 'oh npm is so bloated'. Everytime there is a new app, 'oh electron is so inefficient'. Everytime something is packaged in a docker 'whats the point of containerizing this'. It's really making me sad to browse HN sometimes.

I sympathize with what you're complaining about, but I don't think GP is an instance of that. GP is (rightly, IMO) complaining that the linked article proposes something with extra steps that are not needed, as in: it could be easier than suggested. The typical HN gripes you describe are sort of the inverse of that: complaints that easy-to-use things (electron, npm) are flawed in comparison to their harder-to-use counterparts.

Re: macOS in QEMU in Docker

#64
post #62
post #42

Earlier quoted context omitted.

Honestly that's kind of yikes. That probably just adds extra complexity, and there are better ways to deliver VMs.

> there are better ways to deliver VMs For the curious - what are they?

Not op but they probably mean vagrant?

Re: macOS in QEMU in Docker

#65
post #34
post #16

It's hard to see what Docker is adding here since qemu is being run inside Docker. You could get almost identical functionality out of a bare VM image and not deal with the hassles of docker.

Aren't you being a little too harsh? The Dockerfile automates the installation of libvirt and custom components to launch the VM so while the title might be misleading it is hardly "not adding" anything.

Docker is not adding anything whatsoever. The "dockerfile" could be converted with a simple macro into a plain bash script and it would literally be the same thing. The container is not abstracting anything here; you are using KVM of the host system.

You even have to install more packages in the host than in the container.

You could even just run the original script the Dockerfile is wrapping directly which will even autoinstall the packages for you.

Re: macOS in QEMU in Docker

#66
Can macOS virtual machines ever be performant enough to use as a workstation? So far I have only tried setting it up in VMWare and VirtualBox, the performance wasn't there but I haven't dedicated a GPU or drive to it yet. It would be so convenient to decouple macOS from Mac hardware.

Re: macOS in QEMU in Docker

#67

So this is pretty misleading. It's really a full system emulator (qemu) running inside Docker, using root privileges on the container that make the isolation very weak (--privileged). It also uses hardware assisted virtualization (KVM) which is not going to be available most of the time Docker is. You can think of the Docker platform itself as subset of the Linux platform. With many common features removed by default…

I have run MacOS in QEMU in emulation mode, that was around the time of the first Hackintoshes. You're right, it was very slow (on the hardware of the time.)

Re: macOS in QEMU in Docker

#68
post #42

Earlier quoted context omitted.

its using docker as an artifact delivery mechanism, not as an isolationism mechanism.

Honestly that's kind of yikes. That probably just adds extra complexity, and there are better ways to deliver VMs.

If you have container orchestration in place, being able to use it to run VMs via qemu is actually incredibly useful and isn't really much of a yikes. Sure, you're losing the container's isolation features, but you have a VM there, which is even stronger isolation.

We do CI for our VM images in our kubernetes clusters. The build system already was in kubernetes, so putting the OS image testing in there was a big win.

The benefit of doing this is also that on a personal machine you can start playing with an OSX vm with a single docker run command with no other dependencies and many people already have docker setup, whereas standardized qemu/virtualization tooling is now much less common on developer machines

Re: macOS in QEMU in Docker

#69

Earlier quoted context omitted.

I'm pretty sure since Docker uses bhyve on mac, so that would be a nested VM...

Docker has their own xhyve derivative called hyperkit. Nested VMs are not supported https://github.com/moby/hyperkit/issues/127

If I am not mistaken then xhyve and hyperkit are separate projects utilizing the same Hypervisor Framework from Apple under the hood.

Re: macOS in QEMU in Docker

#70
post #42

Earlier quoted context omitted.

Honestly that's kind of yikes. That probably just adds extra complexity, and there are better ways to deliver VMs.

If you have container orchestration in place, being able to use it to run VMs via qemu is actually incredibly useful and isn't really much of a yikes. Sure, you're losing the container's isolation features, but you have a VM there, which is even stronger isolation. We do CI for our VM images in our kubernetes clusters. The build system already was in kubernetes, so putting the OS image testing in there was a big win.…

I work at Sourcegraph and have been considering something like this for a while for running long-running jobs, things like CI pipelines and GitHub actions for example.

How would you feel about an app like GitLab, for example, shipping a docker container that required privileges for this, I wonder?

Post reply on HN