Skip to content

Apple Container external driver for macOS #3839

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

afbjorklund
Copy link
Member

@afbjorklund afbjorklund commented Aug 15, 2025

A new macOS driver similar to the WSL2 driver for Windows,
creating virtual machines from container images (as rootfs).

Issue #3788

make native && ADDITIONAL_DRIVERS=ac make additional-drivers

(this is a draft, until the driver framework has been finalized)


A new macOS driver similar to the WSL2 driver for Windows,
creating virtual machines from container images (as rootfs).

Signed-off-by: Anders F Björklund <anders.f.bjorklund@gmail.com>
@afbjorklund afbjorklund changed the title Apple Container external driver Apple Container external driver for macOS Aug 16, 2025
if l.Instance != nil {
info.InstanceDir = l.Instance.Dir
}
info.DriverName = "ac"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"ac" isn't a descriptive name.
Can't we just call it "apple-container" ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are breaking @afbjorklund's pun about AC/DC (Apple Container/Debian Container). 🤣

Copy link
Member Author

@afbjorklund afbjorklund Aug 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we will abandon those before merging, also they didn't rhyme with "WSL2" anyway (WC? 🚽)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use "vz" for Virtualization.framework, so I thought we could use "ac" for Apple Container

Copy link
Member Author

@afbjorklund afbjorklund Aug 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Using "cz" is a bit non-obvious, and there is no Containerization.framework - only a Swift library...

/usr/local/bin/container:
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 2000.62.0)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.12)
	/usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.8)
	/usr/lib/liblzma.5.dylib (compatibility version 6.0.0, current version 6.3.0)
	/usr/lib/libarchive.2.dylib (compatibility version 9.0.0, current version 9.2.0)
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1356.0.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 4037.0.0)
	/System/Library/Frameworks/CryptoKit.framework/Versions/A/CryptoKit (compatibility version 1.0.0, current version 1.0.0)
	/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 4037.0.0)
	/System/Library/Frameworks/Network.framework/Versions/A/Network (compatibility version 1.0.0, current version 5569.0.219)
	/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 61901.0.56)
	/System/Library/Frameworks/Virtualization.framework/Versions/A/Virtualization (compatibility version 1.0.0, current version 259.0.0)
	/System/Library/Frameworks/vmnet.framework/Versions/A/vmnet (compatibility version 1.0.0, current version 1.0.0, weak)
	/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
	/usr/lib/swift/libswiftCore.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/swift/libswiftCoreFoundation.dylib (compatibility version 1.0.0, current version 120.100.0, weak)
	/usr/lib/swift/libswiftCoreImage.dylib (compatibility version 1.0.0, current version 2.2.0, weak)
	/usr/lib/swift/libswiftDarwin.dylib (compatibility version 1.0.0, current version 347.0.12)
	/usr/lib/swift/libswiftDispatch.dylib (compatibility version 1.0.0, current version 56.0.0)
	/usr/lib/swift/libswiftIOKit.dylib (compatibility version 1.0.0, current version 1.0.0, weak)
	/usr/lib/swift/libswiftMetal.dylib (compatibility version 1.0.0, current version 370.57.0, weak)
	/usr/lib/swift/libswiftOSLog.dylib (compatibility version 1.0.0, current version 8.0.0, weak)
	/usr/lib/swift/libswiftObjectiveC.dylib (compatibility version 1.0.0, current version 948.0.0, weak)
	/usr/lib/swift/libswiftQuartzCore.dylib (compatibility version 1.0.0, current version 5.0.0, weak)
	/usr/lib/swift/libswiftSynchronization.dylib (compatibility version 1.0.0, current version 0.0.0)
	/usr/lib/swift/libswiftUniformTypeIdentifiers.dylib (compatibility version 1.0.0, current version 874.0.0, weak)
	/usr/lib/swift/libswiftXPC.dylib (compatibility version 1.0.0, current version 105.0.13)
	/usr/lib/swift/libswift_Builtin_float.dylib (compatibility version 1.0.0, current version 0.0.0, weak)
	/usr/lib/swift/libswift_Concurrency.dylib (compatibility version 1.0.0, current version 0.0.0)
	/usr/lib/swift/libswift_StringProcessing.dylib (compatibility version 1.0.0, current version 0.0.0)
	/usr/lib/swift/libswiftos.dylib (compatibility version 1.0.0, current version 1076.0.0)
	/usr/lib/swift/libswiftsimd.dylib (compatibility version 1.0.0, current version 23.0.0, weak)
	/usr/lib/swift/libswift_errno.dylib (compatibility version 1.0.0, current version 347.0.12)
	/usr/lib/swift/libswift_stdio.dylib (compatibility version 1.0.0, current version 347.0.12)
	/usr/lib/swift/libswift_signal.dylib (compatibility version 1.0.0, current version 347.0.12)

The use of "hvf" for Hypervisor.framework and "vz" for Virtualization.framework is confusing enough

- location: "debian-rootfs-arm64.tar.gz"
arch: "aarch64"

# virtiofs is broken
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs description

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is related to an upstream bug, where containers with volumes can't be restarted.

disk: 512GiB

images:
- location: "debian-rootfs-arm64.tar.gz"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Incomplete location

Copy link
Member Author

@afbjorklund afbjorklund Aug 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was built from source: #3788 (comment) - but needs to be hosted somewhere, like the Finch image.

# Source: https://github.com/runfinch/finch-core/blob/main/rootfs/Dockerfile (image based on fedora)
- location: "https://deps.runfinch.com/common/x86-64/finch-rootfs-production-amd64-1741837119.tar.gz"

arch: aarch64
cpus: 4
memory: 1GiB
disk: 512GiB
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other template files do not set cpus, memory, disk, etc.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it predates the code that actually forwarded those flags... Disk seems to be hardcoded, though.

# when using a WSL2 VM.
[ "$LIMA_CIDATA_VMTYPE" = "wsl2" ] || exit 0
# when using a WSL2 or AC VM.
[ "$LIMA_CIDATA_VMTYPE" = "wsl2" ] || [ "$LIMA_CIDATA_VMTYPE" = "ac" ] || exit 0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The provision scripts should not be aware of the VM driver names

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is currently necessary because drivers don't yet have the capability to provide their own boot scripts. We briefly touched on this on Slack in the #lima-gsoc channel1. @unsuman is aware.

Footnotes

  1. https://cloud-native.slack.com/archives/C08KKELMQ92/p1755330101367019?thread_ts=1755325617.281999&cid=C08KKELMQ92

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another option is to introduce a common feature variable ("container" ?), that all three drivers can set.

)

func inspectStatus(instDir string, inst *Instance, y *limayaml.LimaYAML) {
if inst.VMType == limayaml.AC {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This function will be moved to the driver, eventually:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants