41–50 of 59 posts
This is "running debian noVNC clients in Docker that connect to the same macOS host system".
I mean it's great that you use the Apple Virtualization Framework for that on the host service, but that's a different type of VM than a docker VM which would assume syscalls to be abstracted inside the docker container and not on a host service.
But yeah, just my two cents, I guess.
Earlier quoted context omitted.
Yes, you can build and host your own Mac base images directly using the lume CLI. See the usage guide at: https://github.com/trycua/cua/tree/main/libs/lume#usage Currently, lume supports pushing to GitHub Container Registry (GHCR). However, it’s feasible to extend support to any OCI-compatible registry in the future. Steps to build and push a custom image: 1. Start by creating a new VM or pulling an existing image. L…
Thanks! Do you rely on bleeding edge OCI features like artifacts, or on the original features? I'm asking to get a sense of how many registries would work out of the box with this. I'm excited to play with lume! My use case is adding native Mac execution to Dagger ( https://dagger.io ) :)
The relevant code is here: https://github.com/trycua/cua/blob/main/libs/lume/src/Contai...
And thanks again - really appreciate the interest. I’ll follow up via email, would love to hear more about the Dagger use case and how native Mac execution fits in!
This is not "running macOS VMs in Docker". This is "running debian noVNC clients in Docker that connect to the same macOS host system". I mean it's great that you use the Apple Virtualization Framework for that on the host service, but that's a different type of VM than a docker VM which would assume syscalls to be abstracted inside the docker container and not on a host service. But yeah, just my two cents, I guess.
The title could’ve been clearer, but it’s already out there and can’t be edited - appreciate you pointing it out and adding the nuance!
Slightly off topic, does anyone know a good way to run Mac VMs on Linux hosts?
x86 macOS can be done (google is your friend). aarch64 macOS will be much harder since macOS relies on nonstandard extensions to aarch64.
Earlier quoted context omitted.
You’re right, Lumier might seem similar to Lume CLI, but it adds browser-based desktop streaming via noVNC and integrates with Docker for easier management, which is a familiar interface for many developers. Since our parent project C/ua will use KVM-based containers on x86/x64 hosts, aligning to a container interface here seems a natural step for us. Docker also allows packaging noVNC as a self-contained dependency,…
There’s no mention of Tart in there, but I’ve looked into Lume CLI some more and it seems it’s basically a superset of Tart in functionality. (And both use container registries as the VM image store, neat!) > aligning to a container interface here seems a natural step for us It might be tricky since you do have to escape from the container to run the actual VM, though I guess you can figure something out here. I stil…
mkdir -p storage docker run -it --rm \ --name lumier-vm \ -p 8006:8006 \ -v $(pwd)/storage:/storage \ -e VM_NAME=lumier-vm \ -e HOST_STORAGE_PATH=$(pwd)/storage \ trycua/lumier:latest
Looks like your "&&"s might have gotten deleted in the following? mkdir -p storage docker run -it --rm \ --name lumier-vm \ -p 8006:8006 \ -v $(pwd)/storage:/storage \ -e VM_NAME=lumier-vm \ -e HOST_STORAGE_PATH=$(pwd)/storage \ trycua/lumier:latest Would you say that if macOS had namespaces and cgroups it would be much more useful and lightweight for this kind of use case?
And absolutely, if macOS supported namespaces and cgroups natively, it’d open the door to more lightweight, container-native workflows. Right now we work around it with Apple’s Virtualization Framework and treat Docker more as a familiar control plane than a true runtime isolation layer
Earlier quoted context omitted.
Correct. Apple's licensing requires macOS to run on Apple hardware, and limits you to 2 concurrent macOS VMs per host. This is enforced by the Apple Vz framework itself. Some KVM-based solutions bypass these checks, but they aren’t compliant for production use. There’s instead no such limitation when running Linux VMs on a macOS host.
I'm pretty sure the requirement is that the hardware is an Apple Mac, I don't remember macOS being your Hypervisor a requirement. ESXI supports running macOS on Apple Hardware (it extracts the key from the SMC).
See Sequoia's license. Search for 'virtualization'.
D. Virtualization. For each copy of the Apple Software subject to a lease under this Section 3, either a Lessor or a Lessee (but not both) may install, use and run additional copies or instances of the Apple Software within virtual operating system environments in accordance with Section 2B(iii), provided that a Lessor may only virtualize a single instance or copy of the Apple Software as a provisioning tool for the purpose of providing a Lessee with access to and use of the Apple Software pursuant to this Section 3.
(Section 2B) (iii) to install, use and run up to two (2) additional copies or instances of the Apple Software, or any prior macOS or OS X operating system software or subsequent release of the Apple Software, within virtual operating system environments on each Apple-branded computer you own or control that is already running the Apple Software, for purposes of: (a) software development; (b) testing during software development; (c) using macOS Server; or (d) personal, non-commercial use.
Earlier quoted context omitted.
I'm pretty sure the requirement is that the hardware is an Apple Mac, I don't remember macOS being your Hypervisor a requirement. ESXI supports running macOS on Apple Hardware (it extracts the key from the SMC).
That's not correct. See Sequoia's license. Search for 'virtualization'. D. Virtualization. For each copy of the Apple Software subject to a lease under this Section 3, either a Lessor or a Lessee (but not both) may install, use and run additional copies or instances of the Apple Software within virtual operating system environments in accordance with Section 2B(iii), provided that a Lessor may only virtualize a singl…
Why you might ask? Because your existing tooling is already on Linux, so it's easier to manage (for whatever reason) with a semi-homogeneous control plane.