Skip to content

Commit 4802c50

Browse files
authored
Merge pull request #1807 from AkihiroSuda/mv-docs-config
mv docs/{mount,multi-arch,network,vmtype}.md https://lima-vm.io/docs/config/
2 parents c9f9d7c + 533b94b commit 4802c50

File tree

11 files changed

+469
-447
lines changed

11 files changed

+469
-447
lines changed

Makefile

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -77,7 +77,7 @@ else
7777
cp -aL examples _output/share/lima/examples
7878
endif
7979
mkdir -p _output/share/doc/lima
80-
cp -aL *.md LICENSE docs _output/share/doc/lima
80+
cp -aL *.md LICENSE _output/share/doc/lima
8181
echo "Moved to https://github.com/lima-vm/.github/blob/main/SECURITY.md" >_output/share/doc/lima/SECURITY.md
8282
ifneq ($(GOOS),windows)
8383
ln -sf ../../lima/templates _output/share/doc/lima/templates

README.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22
[[📖**Documentations**]](https://lima-vm.io/docs/)
33
[[👤**Slack (`#lima`)**]](https://slack.cncf.io)
44

5-
![Lima logo](./docs/images/lima-logo-01.svg)
5+
<img src="https://lima-vm.io/images/logo.svg" width=400 />
66

77
# Lima: Linux Machines
88

docs/mount.md

Lines changed: 1 addition & 127 deletions
Original file line numberDiff line numberDiff line change
@@ -1,127 +1 @@
1-
# Filesystem mounts
2-
3-
Lima supports several methods for mounting the host filesystem into the guest.
4-
5-
The default mount type is shown in the following table:
6-
7-
| Lima Version | Default |
8-
| ---------------- | ------------------------------------------------------------- |
9-
| < 0.10 | reverse-sshfs + Builtin SFTP server |
10-
| >= 0.10 | reverse-sshfs + OpenSSH SFTP server |
11-
| >= 0.17 | reverse-sshfs + OpenSSH SFTP server for QEMU, virtiofs for VZ |
12-
| >= 1.0 (Planned) | 9p for QEMU, virtiofs for VZ |
13-
14-
## Mount types
15-
16-
### reverse-sshfs
17-
The "reverse-sshfs" mount type exposes the host filesystem by running an SFTP server on the host.
18-
While the host works as an SFTP server, the host does not open any TCP port,
19-
as the host initiates an SSH connection into the guest and let the guest connect to the SFTP server via the stdin.
20-
21-
An example configuration:
22-
```yaml
23-
mountType: "reverse-sshfs"
24-
mounts:
25-
- location: "~"
26-
sshfs:
27-
# Enabling the SSHFS cache will increase performance of the mounted filesystem, at
28-
# the cost of potentially not reflecting changes made on the host in a timely manner.
29-
# Warning: It looks like PHP filesystem access does not work correctly when
30-
# the cache is disabled.
31-
# 🟢 Builtin default: true
32-
cache: null
33-
# SSHFS has an optional flag called 'follow_symlinks'. This allows mounts
34-
# to be properly resolved in the guest os and allow for access to the
35-
# contents of the symlink. As a result, symlinked files & folders on the Host
36-
# system will look and feel like regular files directories in the Guest OS.
37-
# 🟢 Builtin default: false
38-
followSymlinks: null
39-
# SFTP driver, "builtin" or "openssh-sftp-server". "openssh-sftp-server" is recommended.
40-
# 🟢 Builtin default: "openssh-sftp-server" if OpenSSH SFTP Server binary is found, otherwise "builtin"
41-
sftpDriver: null
42-
```
43-
44-
The default value of `sftpDriver` has been set to "openssh-sftp-server" since Lima v0.10, when an OpenSSH SFTP Server binary
45-
such as `/usr/libexec/sftp-server` is detected on the host.
46-
Lima prior to v0.10 had used "builtin" as the SFTP driver.
47-
48-
#### Caveats
49-
- A mount is disabled when the SSH connection was shut down.
50-
- A compromised `sshfs` process in the guest may have an access to unexposed host directories.
51-
52-
### 9p
53-
> **Warning**
54-
> "9p" mode is experimental
55-
56-
The "9p" mount type is implemented by using QEMU's virtio-9p-pci devices.
57-
virtio-9p-pci is also known as "virtfs", but note that this is unrelated to [virtio-fs](https://virtio-fs.gitlab.io/).
58-
59-
An example configuration:
60-
```yaml
61-
mountType: "9p"
62-
mounts:
63-
- location: "~"
64-
9p:
65-
# Supported security models are "passthrough", "mapped-xattr", "mapped-file" and "none".
66-
# "mapped-xattr" and "mapped-file" are useful for persistent chown but incompatible with symlinks.
67-
# 🟢 Builtin default: "none" (since Lima v0.13)
68-
securityModel: null
69-
# Select 9P protocol version. Valid options are: "9p2000" (legacy), "9p2000.u", "9p2000.L".
70-
# 🟢 Builtin default: "9p2000.L"
71-
protocolVersion: null
72-
# The number of bytes to use for 9p packet payload, where 4KiB is the absolute minimum.
73-
# 🟢 Builtin default: "128KiB"
74-
msize: null
75-
# Specifies a caching policy. Valid options are: "none", "loose", "fscache" and "mmap".
76-
# Try choosing "mmap" or "none" if you see a stability issue with the default "fscache".
77-
# See https://www.kernel.org/doc/Documentation/filesystems/9p.txt
78-
# 🟢 Builtin default: "fscache" for non-writable mounts, "mmap" for writable mounts
79-
cache: null
80-
```
81-
82-
The "9p" mount type requires Lima v0.10.0 or later.
83-
84-
#### Caveats
85-
- The "9p" mount type is known to be incompatible with CentOS, Rocky Linux, and AlmaLinux as their kernel do not support `CONFIG_NET_9P_VIRTIO`.
86-
87-
### virtiofs
88-
> **Warning**
89-
> "virtiofs" mode is experimental
90-
91-
| :zap: Requirement | Lima >= 0.14, macOS >= 13.0 | Lima >= 0.17.0, Linux, QEMU 4.2.0+, virtiofsd (Rust version) |
92-
|-------------------|-----------------------------| ------------------------------------------------------------ |
93-
94-
The "virtiofs" mount type is implemented via the virtio-fs device by using apple Virtualization.Framework shared directory on macOS and virtiofsd on Linux.
95-
Linux guest kernel must enable the CONFIG_VIRTIO_FS support for this support.
96-
97-
An example configuration:
98-
```yaml
99-
vmType: "vz" # only for macOS; Linux uses 'qemu'
100-
mountType: "virtiofs"
101-
mounts:
102-
- location: "~"
103-
```
104-
105-
#### Caveats
106-
- For macOS, the "virtiofs" mount type is supported only on macOS 13 or above with `vmType: vz` config. See also [`vmtype.md`](./vmtype.md).
107-
- For Linux, the "virtiofs" mount type requires the [Rust version of virtiofsd](https://gitlab.com/virtio-fs/virtiofsd).
108-
Using the version from QEMU (usually packaged as `qemu-virtiofsd`) will *not* work, as it requires root access to run.
109-
110-
### wsl2
111-
> **Warning**
112-
> "wsl2" mode is experimental
113-
114-
| :zap: Requirement | Lima >= 0.18 + (Windows >= 10 Build 19041 OR Windows 11) |
115-
| ----------------- | -------------------------------------------------------- |
116-
117-
The "wsl2" mount type relies on using WSL2's navite disk sharing, where the root disk is available by default at `/mnt/$DISK_LETTER` (e.g. `/mnt/c/`).
118-
119-
An example configuration:
120-
```yaml
121-
vmType: "wsl2"
122-
mountType: "wsl2"
123-
```
124-
125-
#### Caveats
126-
- WSL2 file permissions may not work exactly as expected when accessing files that are natively on the Windows disk ([more info](https://github.com/MicrosoftDocs/WSL/blob/mattw-wsl2-explainer/WSL/file-permissions.md))
127-
- WSL2's disk sharing system uses a 9P protocol server, making the performance similar to [Lima's 9p](#9p) mode ([more info](https://github.com/MicrosoftDocs/WSL/blob/mattw-wsl2-explainer/WSL/wsl2-architecture.md#wsl-2-architectural-flow))
1+
Moved to <https://lima-vm.io/docs/config/mount/>

docs/mutli-arch.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
Moved to <https://lima-vm.io/docs/config/multi-arch/>

docs/network.md

Lines changed: 1 addition & 235 deletions
Original file line numberDiff line numberDiff line change
@@ -1,235 +1 @@
1-
# Network
2-
3-
## user-mode network (192.168.5.0/24)
4-
5-
By default Lima only enables the user-mode networking aka "slirp".
6-
7-
### Guest IP (192.168.5.15)
8-
9-
The guest IP address is set to `192.168.5.15`.
10-
11-
This IP address is not accessible from the host by design.
12-
13-
Use VMNet (see below) to allow accessing the guest IP from the host and other guests.
14-
15-
### Host IP (192.168.5.2)
16-
17-
The loopback addresses of the host is `192.168.5.2` and is accessible from the guest as `host.lima.internal`.
18-
19-
### DNS (192.168.5.3)
20-
21-
The DNS.
22-
23-
If `useHostResolver` in `lima.yaml` is true, then the hostagent is going to run a DNS server over tcp and udp - each on a separate randomly selected free port. This server does a local lookup using the native host resolver, so it will deal correctly with VPN configurations and split-DNS setups, as well as mDNS, local `/etc/hosts` etc. For this the hostagent has to be compiled with `CGO_ENABLED=1` as default Go resolver is [broken](https://github.com/golang/go/issues/12524).
24-
25-
These tcp and udp ports are then forwarded via iptables rules to `192.168.5.3:53`, overriding the DNS provided by QEMU via slirp.
26-
27-
Currently following request types are supported:
28-
29-
- A
30-
- AAAA
31-
- CNAME
32-
- TXT
33-
- NS
34-
- MX
35-
- SRV
36-
37-
For all other queries hostagent will redirect the query to the nameservers specified in `/etc/resolv.conf` (or, if that fails - to `8.8.8.8` and `1.1.1.1`).
38-
39-
DNS over tcp is rarely used. It is usually only used either when user explicitly requires it, or when request+response can't fit into a single UDP packet (most likely in case of DNSSEC), or in the case of certain management operations such as domain transfers. Neither DNSSEC nor management operations are currently supported by a hostagent, but on the off chance that the response may contain an unusually long list of records - hostagent will also listen for the tcp traffic.
40-
41-
During initial cloud-init bootstrap, `iptables` may not yet be installed. In that case the repo server is determined using the slirp DNS. After `iptables` has been installed, the forwarding rule is applied, switching over to the hostagent DNS.
42-
43-
If `useHostResolver` is false, then DNS servers can be configured manually in `lima.yaml` via the `dns` setting. If that list is empty, then Lima will either use the slirp DNS (on Linux), or the nameservers from the first host interface in service order that has an assigned IPv4 address (on macOS).
44-
45-
## VMNet networks
46-
47-
VMNet assigns a "real" IP address that is reachable from the host.
48-
49-
The configuration steps are different for each network type:
50-
- [socket_vmnet](#socket_vmnet)
51-
- [vzNAT](#vzNAT)
52-
53-
### socket_vmnet
54-
#### Managed (192.168.105.0/24)
55-
56-
[`socket_vmnet`](https://github.com/lima-vm/socket_vmnet) is required for adding another guest IP that is accessible from the host and other guests.
57-
58-
```bash
59-
# Install socket_vmnet
60-
brew install socket_vmnet
61-
62-
# Set up the sudoers file for launching socket_vmnet from Lima
63-
limactl sudoers >etc_sudoers.d_lima
64-
sudo install -o root etc_sudoers.d_lima /etc/sudoers.d/lima
65-
```
66-
67-
> **Note**
68-
>
69-
> Lima before v0.12 used `vde_vmnet` for managing the networks.
70-
> `vde_vmnet` is still supported but it is deprecated and no longer documented here.
71-
72-
The networks are defined in `$LIMA_HOME/_config/networks.yaml`. If this file doesn't already exist, it will be created with these default
73-
settings:
74-
75-
<details>
76-
<summary>Default</summary>
77-
78-
<p>
79-
80-
```yaml
81-
# Path to socket_vmnet executable. Because socket_vmnet is invoked via sudo it should be
82-
# installed where only root can modify/replace it. This means also none of the
83-
# parent directories should be writable by the user.
84-
#
85-
# The varRun directory also must not be writable by the user because it will
86-
# include the socket_vmnet pid file. Those will be terminated via sudo, so replacing
87-
# the pid file would allow killing of arbitrary privileged processes. varRun
88-
# however MUST be writable by the daemon user.
89-
#
90-
# None of the paths segments may be symlinks, why it has to be /private/var
91-
# instead of /var etc.
92-
paths:
93-
# socketVMNet requires Lima >= 0.12 .
94-
# socketVMNet has precedence over vdeVMNet.
95-
socketVMNet: /opt/socket_vmnet/bin/socket_vmnet
96-
# vdeSwitch and vdeVMNet are DEPRECATED.
97-
vdeSwitch: /opt/vde/bin/vde_switch
98-
vdeVMNet: /opt/vde/bin/vde_vmnet
99-
varRun: /private/var/run/lima
100-
sudoers: /private/etc/sudoers.d/lima
101-
102-
group: everyone
103-
104-
networks:
105-
shared:
106-
mode: shared
107-
gateway: 192.168.105.1
108-
dhcpEnd: 192.168.105.254
109-
netmask: 255.255.255.0
110-
bridged:
111-
mode: bridged
112-
interface: en0
113-
# bridged mode doesn't have a gateway; dhcp is managed by outside network
114-
host:
115-
mode: host
116-
gateway: 192.168.106.1
117-
dhcpEnd: 192.168.106.254
118-
netmask: 255.255.255.0
119-
```
120-
121-
</p>
122-
123-
</details>
124-
125-
Instances can then reference these networks from their `lima.yaml` file:
126-
127-
```yaml
128-
networks:
129-
# Lima can manage the socket_vmnet daemon for networks defined in $LIMA_HOME/_config/networks.yaml automatically.
130-
# The socket_vmnet binary must be installed into a secure location only alterable by the admin.
131-
# The same applies to vde_switch and vde_vmnet for the deprecated VDE mode.
132-
# - lima: shared
133-
# # MAC address of the instance; lima will pick one based on the instance name,
134-
# # so DHCP assigned ip addresses should remain constant over instance restarts.
135-
# macAddress: ""
136-
# # Interface name, defaults to "lima0", "lima1", etc.
137-
# interface: ""
138-
```
139-
140-
The network daemon is started automatically when the first instance referencing them is started,
141-
and will stop automatically once the last instance has stopped. Daemon logs will be stored in the
142-
`$LIMA_HOME/_networks` directory.
143-
144-
The IP address is automatically assigned by macOS's bootpd.
145-
If the IP address is not assigned, try the following commands:
146-
```bash
147-
/usr/libexec/ApplicationFirewall/socketfilterfw --add /usr/libexec/bootpd
148-
/usr/libexec/ApplicationFirewall/socketfilterfw --unblock /usr/libexec/bootpd
149-
```
150-
151-
#### Unmanaged
152-
For Lima >= 0.12:
153-
```yaml
154-
networks:
155-
# Lima can also connect to "unmanaged" networks addressed by "socket". This
156-
# means that the daemons will not be controlled by Lima, but must be started
157-
# before the instance. The interface type (host, shared, or bridged) is
158-
# configured in socket_vmnet and not in lima.
159-
# - socket: "/var/run/socket_vmnet"
160-
```
161-
162-
<details>
163-
<summary>For older Lima releases</summary>
164-
165-
<p>
166-
167-
```yaml
168-
networks:
169-
# vnl (virtual network locator) points to the vde_switch socket directory,
170-
# optionally with vde:// prefix
171-
# ⚠️ vnl is deprecated, use socket.
172-
# - vnl: "vde:///var/run/vde.ctl"
173-
# # VDE Switch port number (not TCP/UDP port number). Set to 65535 for PTP mode.
174-
# # Builtin default: 0
175-
# switchPort: 0
176-
# # MAC address of the instance; lima will pick one based on the instance name,
177-
# # so DHCP assigned ip addresses should remain constant over instance restarts.
178-
# macAddress: ""
179-
# # Interface name, defaults to "lima0", "lima1", etc.
180-
# interface: ""
181-
```
182-
</p>
183-
184-
</details>
185-
186-
### vzNAT
187-
188-
> **Warning**
189-
> "vz" mode is experimental
190-
191-
| :zap: Requirement | Lima >= 0.14, macOS >= 13.0 |
192-
|-------------------|-----------------------------|
193-
194-
For [VZ](./vmtype.md) instances, the "vzNAT" network can be configured as follows:
195-
```yaml
196-
networks:
197-
- vzNAT: true
198-
```
199-
200-
The range of the IP address is not specifiable.
201-
202-
The "vzNAT" network does not need the `socket_vmnet` binary and the `sudoers` file.
203-
204-
## Lima user-v2 network
205-
206-
| :zap: Requirement | Lima >= 0.16.0 |
207-
|-------------------|----------------|
208-
209-
user-v2 network provides a user-mode networking similar to the [default user-mode network](#user-mode-network--1921685024-) and also provides support for `vm -> vm` communication.
210-
211-
> **Warning**
212-
> This network mode is experimental
213-
214-
To enable this network mode, define a network with `mode: user-v2` in networks.yaml
215-
216-
```yaml
217-
...
218-
networks:
219-
example-user-v2:
220-
mode: user-v2
221-
...
222-
```
223-
224-
Instances can then reference these networks from their `lima.yaml` file:
225-
226-
```yaml
227-
networks:
228-
- lima: example-user-v2
229-
```
230-
231-
_Note_
232-
233-
- Enabling this network will disable the [default user-mode network](#user-mode-network--1921685024-)
234-
- Subnet used for this network is 192.168.5.0/24 with 192.168.5.2 used for host connection and 192.168.5.3 used for DNS resolution
235-
1+
Moved to <https://lima-vm.io/docs/config/network/>

0 commit comments

Comments
 (0)