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

31–40 of 199 posts

Re: macOS in QEMU in Docker

#31

Post by arghwhat »

Izmaki wrote: post #21

I really hate when "USB Passthrough" is used in situations when, at best, a "USB over ethernet proxy" is what is happening. That's not passthrough... It introduces a whole range of disadvantages that regular passthrough does not (and advanced passthrough might not) have.

Eh? QEMU USB passthrough is true USB passthrough. The problems with USB passthrough stem from issues related to USB controllers themselves and how device enumeration works, with the only better solution being PCIe passthrough of entire USB controllers... Which then present a different set of problems. Speaking from experience in large VM test farms with a significant amount of forwarded hardware.

(However, "USB over ethernet proxy" is also a true passthrough, just one with higher latency than VirtIO.)

Re: macOS in QEMU in Docker

#32

Post by elliotto »

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…

Who cares lol

Re: macOS in QEMU in Docker

#33

Post by user_7832 »

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…

> So, to clarify things: it's QEMU running in a container, and macOS running under QEMU inside it.

A bit tangential but is this more performant/"better" than running MacOS on say Hyper-V? I understand my zen 4 laptop anyway won't allow GPU acceleration, I'm only looking to run a few apps (and maybe Safari) on it.

Re: macOS in QEMU in Docker

#34

Post by ThatMedicIsASpy »

arghwhat wrote: post #31
Izmaki wrote: post #21

I really hate when "USB Passthrough" is used in situations when, at best, a "USB over ethernet proxy" is what is happening. That's not passthrough... It introduces a whole range of disadvantages that regular passthrough does not (and advanced passthrough might not) have.

Eh? QEMU USB passthrough is true USB passthrough. The problems with USB passthrough stem from issues related to USB controllers themselves and how device enumeration works, with the only better solution being PCIe passthrough of entire USB controllers... Which then present a different set of problems. Speaking from experience in large VM test farms with a significant amount of forwarded hardware. (However, "USB over…

On proxmox with a USB DAC/AMP it is impossible to get correct audio without pcie passthrough of the usb controller

Re: macOS in QEMU in Docker

#35

Post by monocasa »

rbut wrote: post #20
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.

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?

Re: macOS in QEMU in Docker

#36

Post by Izmaki »

arghwhat wrote: post #31
Izmaki wrote: post #21

I really hate when "USB Passthrough" is used in situations when, at best, a "USB over ethernet proxy" is what is happening. That's not passthrough... It introduces a whole range of disadvantages that regular passthrough does not (and advanced passthrough might not) have.

Eh? QEMU USB passthrough is true USB passthrough. The problems with USB passthrough stem from issues related to USB controllers themselves and how device enumeration works, with the only better solution being PCIe passthrough of entire USB controllers... Which then present a different set of problems. Speaking from experience in large VM test farms with a significant amount of forwarded hardware. (However, "USB over…

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.

Re: macOS in QEMU in Docker

#37

Post by Izmaki »

ThatMedicIsASpy wrote: post #34
arghwhat wrote: post #31

Earlier quoted context omitted.

Eh? QEMU USB passthrough is true USB passthrough. The problems with USB passthrough stem from issues related to USB controllers themselves and how device enumeration works, with the only better solution being PCIe passthrough of entire USB controllers... Which then present a different set of problems. Speaking from experience in large VM test farms with a significant amount of forwarded hardware. (However, "USB over…

On proxmox with a USB DAC/AMP it is impossible to get correct audio without pcie passthrough of the usb controller

Yeah, isochronous mode is unfortunately not supported for USB passthrough on Proxmox. There were experimental implementations in oVirt back in the days (that is: experimental implementations in a non-prod, only-for-evaluation solution...).

Re: macOS in QEMU in Docker

#38

Post by arghwhat »

Izmaki wrote: post #36
arghwhat wrote: post #31

Earlier quoted context omitted.

Eh? QEMU USB passthrough is true USB passthrough. The problems with USB passthrough stem from issues related to USB controllers themselves and how device enumeration works, with the only better solution being PCIe passthrough of entire USB controllers... Which then present a different set of problems. Speaking from experience in large VM test farms with a significant amount of forwarded hardware. (However, "USB over…

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 states when forwarded and fail to initialize within the VM.

Hardware and drivers are both full of bugs, and things become "fun" when either get surprised. You can deal with it when you're doing the forwarding your own hardware and using your own drivers so discovered issues can be debugged and sorted out, but it's much less fun when you're forwarding stuff from other vendors out of necessity.

Dealt with this one just this morning.

3. Reset bugs. Hardware reset and sequencing is a tricky area (speaking from old FPGA experience), and some devices cannot recover without a full power cycle.

In some cases, I can recover the device by stopping the forward, removing the device (echo 1 > /sys/bus/pci/devices/.../remove), rescanning and letting the host kernel temporarily load drivers and initialize the device, and then forward it again. Did that today.

4. Host crashes. Yay.

Forwarding a single device on a user machine that still gets regular reboots tends to work fine, but things get hairy when you scale this up. I've had to do a lot of automation of things like handing devices back to the hypervisor for recovery and firmware management.

Re: macOS in QEMU in Docker

#39

Post by actionfromafar »

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.

Re: macOS in QEMU in Docker

#40

Post by orbat »

JayDustheadz wrote: post #22

Can this be launched on an M1 Mac? I'm trying to find a way to run a Big Sur VM on my M1 Mac on Monterey/Ventura.

Have you run into Viable https://eclecticlight.co/virtualisation-on-apple-silicon/ or VirtualBuddy https://github.com/insidegui/VirtualBuddy ? I think at least Viable has some limitations though

Edit: "some" limitations is putting it lightly. From https://eclecticlight.co/2022/11/17/lightweight-virtualisati... which is apparently still current:

> Apple’s current implementation of lightweight virtualisation still has no support for Apple ID, iCloud, or any service dependent on them, including Handoff and AirDrop. Perhaps the most severe limitation resulting from this is that you can’t run the great majority of App Store apps, although Apple’s free apps including Pages, Numbers and Keynote can still be copied over from the host and run in a guest macOS.

Same deal with VirtualBuddy, apparently the root of the problem is that some sort of hardware validations fail in VMs https://github.com/insidegui/VirtualBuddy/discussions/27

Post reply on HN