Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

macOS in QEMU in Docker

github.com

Post reply on HN
Print view View original

41–50 of 199 posts

Re: macOS in QEMU in Docker

#41

Post by Izmaki »

arghwhat wrote: post #38
Izmaki wrote: post #36

Earlier quoted context omitted.

I skimmed the README only and just saw the big section of USB over ethernet with the video image and everything, not the tiny mentioning of VFIO above it. Lol. But tell me please, which problems do you have with PCIe passthrough? Also speaking from experience in large VM test farms with a significant amount of forwarded hardware. I've never experienced problems with hundreds of machines doing exactly this, for years.

PCIe passthrough has a few quirks: 1. VMs operate on a copy of certain PCIe descriptors obtained during enumeration/when forwarding was setup, meaning that some firwmare updates that depend on these changing cannot work correctly. The exact details have left my memory. 2. Foo states that only happen when forwarding. Hardware that seems so stable when used directly that bugs would seem inconceivable enter into broken…

Strange... Sounds like you may be doing too many things manually or that what you're testing is the device that is connected directly to USB?

In my case I need 3rd party USB devices (that always just work(™)) to communicate and interact with hardware. Been automating/running literally hundreds of these configurations without a single issue related to USB or PCI passthrough. Even got switchable HUBs for USB in the mix sometimes, too (for power cycling specific USB devices). Works fine as well.

Re: macOS in QEMU in Docker

#42

Post by EspadaV9 »

exe34 wrote: post #29
nine_k wrote: post #17

Earlier quoted context omitted.

Indeed. That would cover a conventionally installed VM, like VirtualBox. But this is packaged as a Docker image, and Docker is Linux-specific. Linux is not officially supported by Apple on their hardware, and is certainly not prevalent on it. I doubt that the intended target audience of this project is limited to Asahi Linux.

I run Linux on a Mac book air, so this would allow me to run macos in a controlled environment if I could think of a good reason to do so.

Not sure that would be the case since it also includes this part

> that is already running the Apple Software

Running Linux on Apple hardware would not follow that part of the EULA.

Re: macOS in QEMU in Docker

#43

Post by nine_k »

monocasa wrote: post #35
rbut wrote: post #20

Earlier quoted context omitted.

Docker can run on macOS (albeit in a VM), but its still running on a Mac "that is already running the Apple Software". So its a perfectly valid option for Mac owners, even if its a VM + container + VM deep.

This requires kvm exposed in the container. Does docker on mac support kvm?

AFAICT, with QEMU, access to KVM is only required if you care about performance %) Otherwise it can emulate everything for you.

Re: macOS in QEMU in Docker

#44

Post by 7bit »

actionfromafar wrote: post #39
nine_k wrote: post #13

So, to clarify things: it's QEMU running in a container, and macOS running under QEMU inside it. This is really nice WRT the ease of installation: no manual setup steps and all. This likely expressly violates the [macOS EULA], which says: «you are granted a limited, non-exclusive license to install, use and run one (1) copy of the Apple Software on a single Apple-branded computer at any one time» — because the point…

How much of these EULAs are actually enforceable though, and in which jurisdictions? Also, wouldn’t it be the end user potentially in violation of the EULA, not the git repo provider? Edit: agreed about OS images, that does not look legit.

GitHub repost are taken down all the time because they offer means to violate EULAs. See youtube-dl which was taken down couple of months back.

Re: macOS in QEMU in Docker

#45

Post by nine_k »

actionfromafar wrote: post #39
nine_k wrote: post #13

So, to clarify things: it's QEMU running in a container, and macOS running under QEMU inside it. This is really nice WRT the ease of installation: no manual setup steps and all. This likely expressly violates the [macOS EULA], which says: «you are granted a limited, non-exclusive license to install, use and run one (1) copy of the Apple Software on a single Apple-branded computer at any one time» — because the point…

How much of these EULAs are actually enforceable though, and in which jurisdictions? Also, wouldn’t it be the end user potentially in violation of the EULA, not the git repo provider? Edit: agreed about OS images, that does not look legit.

Fair. But the docker image provider would be in violation, never having received a license to redistribute macOS images. Without these, the seamless usability aspect is gone, though the repo remains pretty useful because it automates all other steps.

Re: macOS in QEMU in Docker

#46

Post by monocasa »

nine_k wrote: post #43
monocasa wrote: post #35

Earlier quoted context omitted.

This requires kvm exposed in the container. Does docker on mac support kvm?

AFAICT, with QEMU, access to KVM is only required if you care about performance %) Otherwise it can emulate everything for you.

This dockerfile explicitly enables kvm in a way that will cause qemu to fail if it's not present.

Re: macOS in QEMU in Docker

#47

Post by hoistbypetard »

7bit wrote: post #44
actionfromafar wrote: post #39

Earlier quoted context omitted.

How much of these EULAs are actually enforceable though, and in which jurisdictions? Also, wouldn’t it be the end user potentially in violation of the EULA, not the git repo provider? Edit: agreed about OS images, that does not look legit.

GitHub repost are taken down all the time because they offer means to violate EULAs. See youtube-dl which was taken down couple of months back.

This youtube-dl?

https://github.com/ytdl-org/youtube-dl

Did it get taken down again? The takedown I remember was a few years ago, and GitHub announced some policy changes to make it harder for that to happen when they very loudly reinstated it:

https://github.blog/news-insights/policy-news-and-insights/s...

Re: macOS in QEMU in Docker

#48

Post by nottorp »

> Docker-OSX now has a Discord server & Telegram! The Discord is active on #docker-osx and anyone is welcome to come and ask questions, ideas, etc.

No forum eh? Everyone should come to the live channels and ask the same questions again :)

Re: macOS in QEMU in Docker

#49

Post by BoredPositron »

nottorp wrote: post #48

> Docker-OSX now has a Discord server & Telegram! The Discord is active on #docker-osx and anyone is welcome to come and ask questions, ideas, etc. No forum eh? Everyone should come to the live channels and ask the same questions again :)

Discussions are open on their repo...

Re: macOS in QEMU in Docker

#50

Post by arghwhat »

Izmaki wrote: post #41
arghwhat wrote: post #38

Earlier quoted context omitted.

PCIe passthrough has a few quirks: 1. VMs operate on a copy of certain PCIe descriptors obtained during enumeration/when forwarding was setup, meaning that some firwmare updates that depend on these changing cannot work correctly. The exact details have left my memory. 2. Foo states that only happen when forwarding. Hardware that seems so stable when used directly that bugs would seem inconceivable enter into broken…

Strange... Sounds like you may be doing too many things manually or that what you're testing is the device that is connected directly to USB? In my case I need 3rd party USB devices (that always just work(™)) to communicate and interact with hardware. Been automating/running literally hundreds of these configurations without a single issue related to USB or PCI passthrough. Even got switchable HUBs for USB in the mix…

"Manually"? There is only QEMU/KVM, how many layers you put in between does not matter. Proxmox is just a pile of perl scripts doing the same.

My experience is in testing both USB downstream devices and PCIe devices developed in-house. Some of the forwarded devices might be 3rd-party devices like hubs, relays for power cycling and USB isolators to simulate hot-plug, but the DUTs are stuff we manufacture.

In the USB test scenarios (we have about ~100 such machines, on average connected to a dozen DUTs, some more), the symptom of failure is generally that the entire controller can discover downstream devices but permanently fail to communicate with any of them, or that the controller itself fails to initialize entirely.

The PCIe test scenarios is not something I actively work with anymore, but involves a server room full of machines with 4-7 DUTs each and much more custom handling - such as hot-unplugging the device from the VM, resetting and firmware updating the device, and hot-plugging it back as part of the test running in that VM - as testing PCIe devices themselves exercise many more issues that you don't see with standardized hardware.

I have done this for about a decade, so I've been through a few iterations and tech stacks. One can find things that work, but it's not in any way or form guaranteed to work.

Post reply on HN