Network editing: bridge, VLAN, firewall, IPv4/IPv6 (SLAAC), undo #4

2026-11-02T21:45:51+01:00

Duckboot commented

2026-11-02 21:45:51 +01:00

What

Press n in the info screen to edit one network interface of a guest:

bridge, picked from the node's bridges
VLAN tag (empty for none, otherwise 1-4094)
firewall on or off
IPv4: DHCP, static (CIDR plus an optional gateway) or none
IPv6: SLAAC, DHCP, static (CIDR plus an optional gateway) or none

Only the fields you change are rewritten. Everything else in netN (hwaddr, model=MAC, mtu, rate, trunks, type) stays as it is. For a VM, the IP settings go to cloud-init ipconfigN, and only if the VM has a cloud-init drive; they take effect at the next boot. Before anything is sent, a confirm shows the old and new raw values. Press u to put back the values from before your last change to that guest in this session.

Design and API formats: the "Network editing" section of docs/plans/guest-tui-mvp.md.

Notable points

Live finding: changing CT 104 from static IPv4 back to DHCP while it was running left it without IPv4 until it was rebooted. The config was correct; Proxmox does not restart the DHCP client. The confirm now warns that IP changes on a running container may need a reboot.
Undo is cleared on a context switch. VMIDs repeat across clusters, so an undo could otherwise write one cluster's MAC and IP onto another cluster's guest.
Validation: the cloud-init check only looks at disks. CIDR addresses need a decimal prefix, so the netmask form and /0 are rejected. Gateways must match the address family.

Verification

255 tests pass; cv4pve-cli is mocked. hypothesis is added as a dev dependency for a parse/format round-trip test.
ruff check and ruff format --check report no issues.
betterleaks found no secrets.
Read-only round trip on real configs: format_net(parse_net(v)) == v for every netN/ipconfigN of CT 104 and VM 108.
Live test on CT 104: firewall, VLAN 99, IPv6 DHCP and static IPv4 were each applied and then undone with u. net0 ended identical to the baseline. After the DHCP issue above, the CT was rebooted and has its IPv4 and SLAAC addresses again.
Not tested live: changing the bridge, because the node only has vmbr0.

Co-Authored-By: Claude Opus 5.5 noreply@anthropic.com

## What Press `n` in the info screen to edit one network interface of a guest: - bridge, picked from the node's bridges - VLAN tag (empty for none, otherwise 1-4094) - firewall on or off - IPv4: DHCP, static (CIDR plus an optional gateway) or none - IPv6: SLAAC, DHCP, static (CIDR plus an optional gateway) or none Only the fields you change are rewritten. Everything else in `netN` (hwaddr, model=MAC, mtu, rate, trunks, type) stays as it is. For a VM, the IP settings go to cloud-init `ipconfigN`, and only if the VM has a cloud-init drive; they take effect at the next boot. Before anything is sent, a confirm shows the old and new raw values. Press `u` to put back the values from before your last change to that guest in this session. Design and API formats: the "Network editing" section of `docs/plans/guest-tui-mvp.md`. ## Notable points - **Live finding:** changing CT 104 from static IPv4 back to DHCP while it was running left it without IPv4 until it was rebooted. The config was correct; Proxmox does not restart the DHCP client. The confirm now warns that IP changes on a running container may need a reboot. - **Undo is cleared on a context switch.** VMIDs repeat across clusters, so an undo could otherwise write one cluster's MAC and IP onto another cluster's guest. - **Validation:** the cloud-init check only looks at disks. CIDR addresses need a decimal prefix, so the netmask form and `/0` are rejected. Gateways must match the address family. ## Verification - 255 tests pass; `cv4pve-cli` is mocked. `hypothesis` is added as a dev dependency for a parse/format round-trip test. - `ruff check` and `ruff format --check` report no issues. - `betterleaks` found no secrets. - Read-only round trip on real configs: `format_net(parse_net(v)) == v` for every `netN`/`ipconfigN` of CT 104 and VM 108. - Live test on CT 104: firewall, VLAN 99, IPv6 DHCP and static IPv4 were each applied and then undone with `u`. `net0` ended identical to the baseline. After the DHCP issue above, the CT was rebooted and has its IPv4 and SLAAC addresses again. - Not tested live: changing the bridge, because the node only has `vmbr0`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Duckboot added 1 commit 2026-11-02 21:45:51 +01:00

Add network editing with VLAN, firewall, IPv4/IPv6 and undo 5038148686

Press n in the info screen to edit one interface: bridge, VLAN tag,
firewall, IPv4 (DHCP, static or none) and IPv6 (SLAAC, DHCP, static or
none). The netN string is parsed, the chosen fields are changed and
the string is written back, so hwaddr, model=MAC, mtu, rate, trunks
and type are kept. For VMs, IP settings go to cloud-init ipconfigN and
only when the VM has a cloud-init drive.

A confirm shows the old and new raw values before anything is sent.
Press u to restore the values from before the last change to that
guest in this session.

Review fixes:
- Undo entries are cleared on a context switch, because VMIDs repeat
  across clusters.
- has_cloudinit only looks at disks.
- CIDR needs a decimal prefix: no netmask form and no /0.
- Fields you did not touch are not rewritten.

Live test on CT 104: firewall, VLAN 99, IPv6 DHCP and static IPv4 were
each applied and undone, and net0 ended identical to the baseline.
Going from static back to DHCP left the CT without IPv4 until a
reboot, so the confirm now warns that IP changes on a running
container may need one.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

Duckboot merged commit 5038148686 into main

2026-11-02 21:45:59 +01:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Duckboot/cv4pve-cli-tui#4