-
Notifications
You must be signed in to change notification settings - Fork 696
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
base: master
Are you sure you want to change the base?
Conversation
6c1f904
to
33feb79
Compare
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>
if l.Instance != nil { | ||
info.InstanceDir = l.Instance.Dir | ||
} | ||
info.DriverName = "ac" |
There was a problem hiding this comment.
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" ?
There was a problem hiding this comment.
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). 🤣
There was a problem hiding this comment.
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? 🚽)
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs description
There was a problem hiding this comment.
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" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Incomplete location
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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:
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)