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

LXD containers on macOS at near-native speeds

beringresearch.github.io

Post reply on HN
Print view View original

21–30 of 134 posts

Re: LXD containers on macOS at near-native speeds

#21

Post by gpanders »

hannibalhorn wrote: post #5
miohtama wrote: post #2

This is good news. I come from the development background and the number one use case of containers on macOS is development enviroments, as on Windows too. For this use case, file system IO has always been bottleneck, not CPU. I do not know if there is some silver bullet in the horizon that could make this faster.

I've been really impressed with what I can accomplish with lima-vm, beyond just "replace docker desktop". The latest pre-release supports Virtualization.framework, including virtiofs.

Last I checked (which was not that long ago), Lima was stuck using 9p because QEMU for Darwin didn’t yet support virtiofs. Has this changed? Or maybe I’m just misremembering the details…

EDIT: Looks like this was indeed just added in the last couple of weeks https://github.com/lima-vm/lima/commit/c18ae239b69a47db77436...

Re: LXD containers on macOS at near-native speeds

#22

Post by ricardobeat »

st3fan wrote: post #8
est wrote: post #3

> Prerequisites Install QEMU So in other words, qemu runs at near-native speeds?

Yes, on recent MacOS it is mostly just an abstraction on top of the native Virtualization Framework.

Not if you’re running x86 emulation on an ARM host. It’s terribly slow.

EDIT: This is from experience. When I started using a M1 mac, our docker builds on x86 images took up to 5x or 10x longer vs running on an arm64 image. Had slightly faster, but similar results running my own docker host on Lima, or podman, or building without docker inside a UTM host which also uses qemu.

Re: LXD containers on macOS at near-native speeds

#24

Post by [deleted] »

hannibalhorn wrote: post #5
miohtama wrote: post #2

This is good news. I come from the development background and the number one use case of containers on macOS is development enviroments, as on Windows too. For this use case, file system IO has always been bottleneck, not CPU. I do not know if there is some silver bullet in the horizon that could make this faster.

I've been really impressed with what I can accomplish with lima-vm, beyond just "replace docker desktop". The latest pre-release supports Virtualization.framework, including virtiofs.

[deleted]

Re: LXD containers on macOS at near-native speeds

#25

Post by jbverschoor »

ricardobeat wrote: post #22
st3fan wrote: post #8

Earlier quoted context omitted.

Yes, on recent MacOS it is mostly just an abstraction on top of the native Virtualization Framework.

Not if you’re running x86 emulation on an ARM host. It’s terribly slow. EDIT: This is from experience. When I started using a M1 mac, our docker builds on x86 images took up to 5x or 10x longer vs running on an arm64 image. Had slightly faster, but similar results running my own docker host on Lima, or podman, or building without docker inside a UTM host which also uses qemu.

I don’t think that’s true.

https://developer.apple.com/documentation/virtualization/run...

Re: LXD containers on macOS at near-native speeds

#27

Post by [deleted] »

jbverschoor wrote: post #25
ricardobeat wrote: post #22

Earlier quoted context omitted.

Not if you’re running x86 emulation on an ARM host. It’s terribly slow. EDIT: This is from experience. When I started using a M1 mac, our docker builds on x86 images took up to 5x or 10x longer vs running on an arm64 image. Had slightly faster, but similar results running my own docker host on Lima, or podman, or building without docker inside a UTM host which also uses qemu.

I don’t think that’s true. https://developer.apple.com/documentation/virtualization/run...

[deleted]

Re: LXD containers on macOS at near-native speeds

#28

Post by eurasiantiger »

zweifuss wrote: post #18
ryanmccullagh wrote: post #4

Does QEMU emulate the CPU on macOS?

Depends. QEMU can use Apple's Hypervisor virtualization framework to run ARM64 operating systems on Apple Silicon without emulation. It seems to be possible to then use Rosetta 2 to run x64-code on those operating systems.

Can confirm this works, but some applications will be slow. Seen a magnitude of difference with x86 JVM containers between Rosetta 2 and native ARM64.

Re: LXD containers on macOS at near-native speeds

#29

Post by runeks »

ricardobeat wrote: post #22
st3fan wrote: post #8

Earlier quoted context omitted.

Yes, on recent MacOS it is mostly just an abstraction on top of the native Virtualization Framework.

Not if you’re running x86 emulation on an ARM host. It’s terribly slow. EDIT: This is from experience. When I started using a M1 mac, our docker builds on x86 images took up to 5x or 10x longer vs running on an arm64 image. Had slightly faster, but similar results running my own docker host on Lima, or podman, or building without docker inside a UTM host which also uses qemu.

No, it's decent performance. Minimum 25% of native, and even more using Rosetta: https://news.ycombinator.com/item?id=32149080

Re: LXD containers on macOS at near-native speeds

#30

Post by barefeg »

I like the progress that is being made for running containerized workloads on macOS. In my case I like some of the benefits of running the workload on a remote machine; such as no fan noise, less heat, less power consumption (especially on laptops). However the downsides can be also quite annoying, such as file sync times or IDE input lag.

My current setup is to have both data and workload run on a remote machine and I connect to it via SSH. I can either run neovim inside or use the remote development plugin from VSCode. But as mentioned, the input lag can be very annoying. I’m wondering if there’s another setup where I can still retain some of the upsides of running the workloads remotely and still having a decent user experience (reduced lag)

Post reply on HN