Why we built Lume: - Run native macOS VMs in 1 command, using Apple Virtualization.Framework: `lume run macos-sequoia-vanilla:latest`
- Prebuilt images on https://ghcr.io/trycua (macOS, Ubuntu on ARM)
- API server to manage VMs programmatically `POST /lume/vms`
- A python SDK on github.com/trycua/pylume
Run prebuilt macOS images in just 1 step: lume run macos-sequoia-vanilla:latest
How to Install:
brew tap trycua/lume
brew install lume
You can also download the `lume.pkg.tar.gz` archive from the latest release https://github.com/trycua/lume/releases, extract it, and install the package manually.
Local API Server: `lume` exposes a local HTTP API server that listens on `http://localhost:3000/lume`, enabling automated management of VMs.
lume serve
For detailed API documentation, please refer to API Reference(https://github.com/trycua/lume/blob/main/docs/API-Reference....).
HN devs - would love raw feedback on the API design and whether this solves your Apple Silicon VM pain points. What would make you replace UTM/Multipass/Docker Desktop with this?
Repo: https://github.com/trycua/lume Python SDK: github.com/trycua/pylume Discord for direct feedback: https://discord.gg/8p56E2KJ
the hard part about running VMs isn't really how to launch them (well, ahem, i'm looking at you, qemu), but getting data in and out, and controlling them. some feature requests, if i may ;)
# take screenshot
# this should do the right thing(TM) and take a screenshot of the logged-in user session, which may not necessarily be the console
lume screenshot <vm name> [-o <file.png> | -]
# execute command
lume exec <vm name> [--as-user <user>] <command> [args]
# copy files in and out
lume cp <vm name>:<vm path> <local path>
lume cp <local path> <vm name>:<vm path>
# run clone as new VM
# this should appropriately roll the MAC address, IPs, and reseed any RNGs, of course
lume run --clone <clone name> <vm name>
The ability to resume a VM within < 1 second would be useful for on-demand workflows without waiting for a full VM bootup sequence, similar to how you can get a firecracker microVM into the state you want, snapshot it.. then clone as you wish, and resume back into the guest.
You may need to preinstall an agent (a la Parallel/VMware Tools) to make sure this is seamless and fast.
Interestingly, we left out the screenshot and exec features from this initial release so the CLI wouldn’t get too cluttered. We’re rolling out another update next week that will let you request screenshots programmatically, stream the VNC session in your browser via noVNC, run commands remotely over SSH, add clipboard support (finally!), and more.
As for cloning, you can indeed clone a running VM. However, suspending a VM isn’t supported in this release yet, even though it’s possible with the Apple Virtualization.framework. I’ll open an issue to track that work. Thanks again for the suggestions!
Also, would it be possible to run BSDs with this?
[2] https://tart.run
I'll definitely document the option in the README, thanks!
On Lima:
- Lima focuses on Linux VMs and doesn't support managing macOS VMs.
- It is more of a container-oriented way of spinning up Linux VMs. We're still debating whether to go in that direction with lume, but the good news is that it would mostly require tweaking the hooks to expose lume’s core to adopt the containerd standard. I’d love to hear your thoughts - would you find it useful to have a Docker-like interface for starting macOS workloads? Similarly to: https://github.com/qemus/qemu-docker
- Still many dependencies on QEMU, which doesn't play well with Apple silicon - while we opted to support only M chips (80-90% of the market cap today) by relying on the latest Apple Virtualization.Framework bits.
On Tart:
- We share some similarities when it comes to tart's command-line interface. We extend it and make it more accessible to different frameworks and languages with our local server option (lume serve). We have also an interface for python today: https://github.com/trycua/pylume
- Going forward, we'd like to focus more on creating tools around developers, creating tools for automation and extending the available images in our ghcr registry. Stay tuned for more updates next week!
- Lastly, lume is licensed under MIT, so you’re free to use it for commercial purposes. Tart, on the other hand, currently uses a Fair Source license.
I think it is great to have more options in this space, as all of these options are still quite immature. In terms of approaches to take, I find one of the challenges in using lima is that, they way lima works makes the VM different enough from production that I can't be confident testing covers everything.
In terms of feature set, I think some of these have been mentioned below, but these would be great: - network bridging - snapshotting - usb / bluetooth passthrough (this is probably dependent on Apple's framework)
- OpenWRT (previously OPNSense & once Mikrotik RouterOS) using 2x 2.5Gbps Ethernet NICs via USB-C
- OpenMediaVault (Exposing a 4-bay DAS via USB-C, 2x3TB Drives in Btrfs RAID-1)
- HassOS (Home Assistant OS)
On the host, I'm running OLlama and a reverse proxy through Docker.
The whole thing uses 7 watts of power at any given time - I've seen max peaks of 12w when running LLM queries. The drive bay actually uses more than it.
Through power saving alone, it will pay for itself in 5 years over my previous AMD Zen 2 build.
I understand for specific MacOS or iOS development wanting template envs one would want to easily and repeatedly spawn up / destroy.
We have a Mac Studio dedicated to that purpose. Periodically something on it stops working (software updates are a common reason). Trying to run CI/CD on a bare metal consumer oriented OS is an exercise in frustration.
It’s also handy to be able to sandbox different environments from each other. Once you have multiple projects that need different versions of Xcode, or even macOS (a good example is wanting to spin things on a beta), you need VMs or multiple machines. (And yes I’m aware of tools like Xcodes, but testing on a beta of macOS requires a reboot and a lengthy install.)
All the things Apple puts in place to make macOS more secure and consumer friendly make it really hard to manage as a server, especially if you don't want to use MDM. For example with the current version of macOS, the macOS AMI that Amazon provides requires manually logging in over screen sharing to enable local networking. So I haven't updated to Sequoia yet. As it is, my AMI build process is fully automated but still takes almost 2 hours and involves first mounting the Amazon AMI to a Linux instance to modify parts of the image that are read-only when it's booted from.
Our current CI/CD process is to create a unique build user per build, then tear it down afterwards. EC2 has something called root volume replacement to allow you to reset a machine to its AMI, but that still takes too long (~ 10 minutes) to do between every build.
(At least with EC2 Macs I no longer need to open a ticket with DC ops when there's a hardware issue.)
Using macOS VMs that can be quickly reset makes this all a lot easier, more flexible, secure, and cleaner. The only currently viable options I'm aware of are tart and anka. I'm glad to see some open source competition in this space.
Worked well for my simple use case.
So, like Docker but without the part where it's fast or convenient!
We're currently working out the details. It was left out of the initial release, but it’s feasible starting from a Windows on ARM image. I'll create an issue to track this work. Thanks for the feedback!
Just checked my list of VMs in UTM; 5 Linux (Ubuntu, Debian, and Fedora), 9 Mac OS X/OS X/macOS (versions stretching back from Tiger to Sequoia), and 10 Windows (XP through 11). Lume would need to support not only Windows but also emulation in order to consider a move.
brew install orbstack
orb
# you're now running in an ubuntu VMThe project looks cool though
- FOSS: Free / open source software
- OSS: Open source software.
Edit: Did a quick google search and it seems like the acronym OSS has fallen out of prominence. Probably best to explicitly state “Open Source” nowadays to avoid any confusion.
For laptops, there are many nice options. But for tablets, the latest iPads are currently unmatched at under 600 grams for a 13" tablet. So I would love to use one of those.
If so, this would be great. Particularly to repurpose older macs.
Everything server related that is easy to do on Linux or BSD is at least an order of magnitude more painful on macOS. And like Windows, you cannot run it headless. In fact Windows actually had better support for running headless than macOS despite macOS’s unix heritage.
Also if you need to run macOS on anything other than spare hardware, then expect to pay a premium. This is particularly true of hosting macOS instances in the cloud.
Every time I’ve needed to run macOS as a server, which is a depressingly large amount of times over the years — I’ve had to do that in every job bar one — it’s been a painful process and I’ve had to accept compromises to what would normally be best practices.
Stuff like Tart does make things a little easier. But given how locked down macOS and its hardware are, it really should be something Apple gave a lot more love to themselves. Instead they went the other way and discontinued Mac Server, albeit that was some number of years ago now. And things haven’t gotten any better since.
As a battle hardened unix greybeard, I’d still prefer to administrate enterprise Windows server over “enterprise macOS” servers.
That all said, for any hobby projects, anything is fair game. So if you have spare hardware then go for it. Just don’t expect it to be as “fun” as running Debian on a Rasberry Pi or similar other traditional hobby set ups
As an FYI for anyone who needs/wants to do this, the workaround is a headless display adapter: https://www.amazon.com/dp/B0D9W2HHM1
Also, the frequency and size and time to install MacOS updates - like these computers are blazingly fast from the cpus to the SSDs - after an update has downloaded, what could it possibly be doing that takes 30+ minutes to install? I've never had to wait for an apt-get upgrade that long.
On a package-based system you're doing a diff update, essentially.
Then again, even Fedora Silverblue image updates don't take nearly as long as macOS.
At least both are better than Windows, god knows what's going on in Microsoft's update process.
Assuming they're using some fast parallel compression algo as well when unpacking it...