lee/container
1
0
Fork 0
mirror of https://github.com/apple/container.git synced 2026-08-29 03:46:39 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: update version description (#42)

Browse Source 
Updating version descriptions so we're consistent across repos.

Signed-off-by: Eric Ernst <eric_ernst@apple.com>
This commit is contained in:
Eric Ernst
2025-06-08 18:02:44 -07:00
committed by GitHub
parent ff59bb38e8
commit 8fcbd01678
3 changed files with 9 additions and 9 deletions
Download Patch File Download Diff File Expand all files Collapse all files
BUILDING.md
+1 -1
View File
@@ -2,7 +2,7 @@
To build the `container` project, your system needs either:
- macOS Sequoia 15 or newer and Xcode 17 beta.
- macOS 15 or newer and Xcode 17 beta.
- macOS Developer Preview.
## Compile and test
README.md
+2 -2
View File
@@ -17,9 +17,9 @@ Install `container` on your Mac.
You need an Apple silicon Mac to run `container`. To build it, see the [BUILDING](./BUILDING.md) document.
`container` is designed to use the new features in the macOS Developer Preview. You can run the tool on macOS Sequoia 15, but the `container` maintainers typically will not address issues discovered on macOS Sequoia 15 that cannot be reproduced on the macOS Developer Preview.
`container` is designed to use the new features in the macOS Developer Preview. You can run the tool on macOS 15, but the `container` maintainers typically will not address issues discovered on macOS 15 that cannot be reproduced on the macOS Developer Preview.
There are [significant networking limitations](/docs/technical-overview.md#macos-sequoia-15-limitations) that impact the usability `container` on macOS Sequoia 15.
There are [significant networking limitations](/docs/technical-overview.md#macos-15-limitations) that impact the usability `container` on macOS 15.
### Install or upgrade
docs/technical-overview.md
+6 -6
View File
@@ -65,19 +65,19 @@ The macOS Virtualization framework implements only partial support for memory ba
Currently, memory pages freed to the Linux operating system by processes running in the container's VM are not relinquished to the host. If you run many memory-intensive containers, you may need to occasionally restart them to reduce memory utilization.
### macOS Sequoia 15 limitations
### macOS 15 limitations
`container` relies on the new features and enhancements present in the macOS Developer Preview. You can run `container` on macOS Sequoia 15, but you will need to be aware of some user experience quirks and functional limitations. There is no plan to address issues found with macOS Sequoia 15 that cannot be reproduced in the macOS Developer Preview.
`container` relies on the new features and enhancements present in the macOS Developer Preview. You can run `container` on macOS 15, but you will need to be aware of some user experience quirks and functional limitations. There is no plan to address issues found with macOS 15 that cannot be reproduced in the macOS Developer Preview.
#### Network isolation
The vmnet framework in macOS Sequoia 15 can only provide networks where the attached containers are isolated from one another. Container-to-container communication over the virtual network is not possible.
The vmnet framework in macOS 15 can only provide networks where the attached containers are isolated from one another. Container-to-container communication over the virtual network is not possible.
#### Container IP addresses
In macOS Sequoia 15, limitations in the vmnet framework mean that the container network can only be created when the first container starts. Since the network XPC helper provides IP addresses to containers, and the helper has to start before the first container, it is possible for the network helper and vmnet to disagree on the subnet address, resulting in containers that are completely cut off from the network.
In macOS 15, limitations in the vmnet framework mean that the container network can only be created when the first container starts. Since the network XPC helper provides IP addresses to containers, and the helper has to start before the first container, it is possible for the network helper and vmnet to disagree on the subnet address, resulting in containers that are completely cut off from the network.
Normally, vmnet creates the container network using the CIDR address 192.168.64.1/24, and on macOS Sequoia 15, `container` defaults to using this CIDR address in the network helper. To diagnose and resolve issues stemming from a subnet address mismatch between vmnet and the network helper:
Normally, vmnet creates the container network using the CIDR address 192.168.64.1/24, and on macOS 15, `container` defaults to using this CIDR address in the network helper. To diagnose and resolve issues stemming from a subnet address mismatch between vmnet and the network helper:
- Before creating the first container, scan the output of the command `ifconfig` for all bridge interface named similarly to `bridge100`.
- After creating the first container, run `ifconfig` again, and locate the new bridge interface to determine container the subnet address.
@@ -88,4 +88,4 @@ Normally, vmnet creates the container network using the CIDR address 192.168.64.
defaults write com.apple.container.defaults default.subnet 192.168.66.1/24
```
- Run `container system start` to launch services again.
- Try running the container again and verify that its IP address matches the current bridge interface value.
- Try running the container again and verify that its IP address matches the current bridge interface value.