b0c9d1c9
docs: v0.0.7 release notes
a73x 2026-08-14 17:34
Commit message
docs/releases.md
| Old | New | ||
|---|---|---|---|
| @@ -5,6 +5,56 @@ Tarballs and checksums for every release live at | |||
| 5 | newest. The [quickstart](quickstart.md) takes a release from download to a | 5 | newest. The [quickstart](quickstart.md) takes a release from download to a |
| 6 | running VM. | 6 | running VM. |
| 7 | 7 | ||
| 8 | ## v0.0.7 | ||
| 9 | |||
| 10 | A VM can be a machine on your network. Declare a bridge on a Linux host, name | ||
| 11 | it to the agent, pick that name at create — the guest gets a second NIC on your | ||
| 12 | LAN, addressed by your own DHCP server, while keeping everything it already | ||
| 13 | had: NAT egress, the gate, published ports, its neighbours. The thing that made | ||
| 14 | you reach for multipass — a VM your other machines can just talk to, running a | ||
| 15 | service that advertises its own address — is now one field on create. | ||
| 16 | |||
| 17 | **A named network is a second life, not a different one.** The guest's private | ||
| 18 | NIC stays: eitri still reaches it there, other guests on the host still reach | ||
| 19 | it there, and outbound still leaves through the host. The second NIC is where | ||
| 20 | your network meets it. Which address a service advertises is that service's | ||
| 21 | own business. | ||
| 22 | |||
| 23 | **The address is discovered, not invented.** Your DHCP server owns that | ||
| 24 | network, so eitri watches the guest's own lease exchange and reports what was | ||
| 25 | granted — the console's **Network** row carries your name for the network and | ||
| 26 | the address the rest of it knows the guest by. A guest configured static there | ||
| 27 | is reachable all the same; eitri just has nothing to report. | ||
| 28 | |||
| 29 | **Your network is protected from its guests.** A guest cannot forge its own | ||
| 30 | reported address — eitri believes only frames that arrived from your side of | ||
| 31 | the wire — and it cannot answer DHCP onto your network at all: lease offers | ||
| 32 | from a guest are dropped at the tap, before the bridge can carry them to a | ||
| 33 | sibling, your real machines, or the switch. | ||
| 34 | |||
| 35 | **Refusals name the fix, wherever you ask from.** A create naming a network | ||
| 36 | its host does not advertise says what that host does serve; a Mac is told its | ||
| 37 | OS cannot serve named networks rather than told to set a flag its agent would | ||
| 38 | refuse; an agent given `--host-network` for a bridge that is missing refuses | ||
| 39 | to start, naming it. Over MCP, `vm_create` takes the same `network` field, | ||
| 40 | reports the discovered address, and default placement picks a host that | ||
| 41 | actually serves the network you asked for. | ||
| 42 | |||
| 43 | **Known limits.** | ||
| 44 | |||
| 45 | - Named networks are Linux-host only. A Mac agent given `--host-network` | ||
| 46 | refuses to start; place bridged guests on a Linux host. | ||
| 47 | - A host serving named networks needs the kernel's nftables bridge family; an | ||
| 48 | agent that cannot program it refuses to start and names the command. Hosts | ||
| 49 | with no named networks are untouched. | ||
| 50 | - A bridged guest cannot serve DHCPv4 onto that network — deliberate, so a | ||
| 51 | guest can never hand out leases to your real machines. DHCPv6 and router | ||
| 52 | advertisements are not filtered: a bridged guest is a full peer, and some of | ||
| 53 | yours may be routers on purpose. | ||
| 54 | - The private NIC keeps the default route via route metrics the default | ||
| 55 | Ubuntu image honours; an image whose distro renders cloud-init's network | ||
| 56 | config without netplan may order its own routes. | ||
| 57 | |||
| 8 | ## v0.0.6 | 58 | ## v0.0.6 |
| 9 | 59 | ||
| 10 | The distance from a token to a running VM. `eitri init` is one guided command | 60 | The distance from a token to a running VM. `eitri init` is one guided command |