Live data from Hacker News

LXD containers on macOS at near-native speeds

beringresearch.github.io

31–40 of 134 posts

Re: LXD containers on macOS at near-native speeds

#31
post #12
post #6

I experimented with LXD containers on Linux recently, but I found the technology it builds on (cgroups) too hard to wrap my head around, and tutorials leave me in the dark. E.g. here is page 2 of one tutorial: https://access.redhat.com/documentation/en-us/red_hat_enterp... All these rules made no sense to me, and while I suppose they become clear at some point, I like my tutorials to be clear from the start.

That's documentation for RHEL 6 which is now 12 years old. It pertains to cgroups v1 which was horribly complex. It was replaced by cgroups v2 which is much simpler; there's now a single hierarchy of cgroups. https://access.redhat.com/documentation/en-us/red_hat_enterp... That said I don't remember having to learn all that much about cgroups when I last looked at lxc...

Thanks!

Well, I started looking into it because there were all these mounted filesystems that I couldn't unmount, even as root. I guess I will have to look into namespaces also.

Re: LXD containers on macOS at near-native speeds

#32
post #10
post #6

I experimented with LXD containers on Linux recently, but I found the technology it builds on (cgroups) too hard to wrap my head around, and tutorials leave me in the dark. E.g. here is page 2 of one tutorial: https://access.redhat.com/documentation/en-us/red_hat_enterp... All these rules made no sense to me, and while I suppose they become clear at some point, I like my tutorials to be clear from the start.

lxd is so much easier than alternatives like systemd-nspawn. 3 minutes search reveals an easy to follow tutorial. https://ubuntu.com/server/docs/containers-lxd

Thanks but I wasn't talking about lxd, but about the underlying technology.

Re: LXD containers on macOS at near-native speeds

#33
post #31
post #12

Earlier quoted context omitted.

That's documentation for RHEL 6 which is now 12 years old. It pertains to cgroups v1 which was horribly complex. It was replaced by cgroups v2 which is much simpler; there's now a single hierarchy of cgroups. https://access.redhat.com/documentation/en-us/red_hat_enterp... That said I don't remember having to learn all that much about cgroups when I last looked at lxc...

Thanks! Well, I started looking into it because there were all these mounted filesystems that I couldn't unmount, even as root. I guess I will have to look into namespaces also.

Yeah, it's pretty much an implementation detail - the thing running your containers likely exposes knobs like 'memory limit' and 'cpu limit' and under the hood it takes care of manipulating the files within the mounted cgroup filesystem.

You'll be pleased that at least with cgroups v2 there's only a single /sys/fs/cgroup instead of half a dozen filesystems mounted underneath that path. :)

Re: LXD containers on macOS at near-native speeds

#34
This is cool and a worthwhile thing, but how is this different than the many (b/x)hyve clones and others based on QEMU that use MacOS’s virtualization framework to run a minimal Linux for containers? What’s the differentiator that makes this better (hopefully?) from what’s come before?

Re: LXD containers on macOS at near-native speeds

#35
post #15

Earlier quoted context omitted.

Wait, what? QEMU can pass x86 instructions directly to Rosetta without emulating an entire host OS?

It does emulate the OS (it’s the point of running stuff in qemu ) but doesn’t translate the instructions

> It does emulate the OS (it’s the point of running stuff in qemu)

The point of running stuff in qemu is to virtualize / emulate the hardware. You still need a “normal” OS inside qemu.

Re: LXD containers on macOS at near-native speeds

#37
post #30

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…

If you're on Kubernetes remotely, Telepresence [0] might be worth a look.

[0] https://www.telepresence.io

Re: LXD containers on macOS at near-native speeds

#38
At first, I thought this was based on a syscall compatibility layer like Solaris' Linux Zones or WSL1 (RIP), or the Linux support in FreeBSD and NetBSD.

If you've ever tried to spin up a whole bunch of Docker containers in WSL2 and watched `vmmem` memory and CPU usage explode, you know that 'near-native speed' in VMs comes with lots of asterisks.

Does macOS have usable native macOS containers yet?

Re: LXD containers on macOS at near-native speeds

#39

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

#40
So is there some canonical guide to running a docker compose style app on Mac m1 machines that has good filesystem performance? It seems like there’s many ways to approach the topic now so it’s hard to tell which one is “winning”.

I’d love to containerize all of my local development efforts (scripts and rails apps) but the slow ass filesystem always ruined it in the past.

Post reply on HN