pv1-2: VLAN-aware vmbr0, template 9101 (Steps 1-2 done)
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
@@ -5,8 +5,8 @@ Pairs with [docs/plans/2026-09-29-2315-pv1-2-workers.md](../plans/2026-09-29-231
|
|||||||
## Status
|
## Status
|
||||||
|
|
||||||
- [x] Step 0 — Record the plan
|
- [x] Step 0 — Record the plan
|
||||||
- [ ] Step 1 — `vmbr0` on `pv1-2` VLAN-aware (owner)
|
- [x] Step 1 — `vmbr0` on `pv1-2` VLAN-aware (owner)
|
||||||
- [ ] Step 2 — Template 9101 on `pv1-2` (owner)
|
- [x] Step 2 — Template 9101 on `pv1-2` (owner)
|
||||||
- [ ] Step 3 — Second worker MachineDeployment `lab1-workers-pv1-2`
|
- [ ] Step 3 — Second worker MachineDeployment `lab1-workers-pv1-2`
|
||||||
- [ ] Step 4 — Scale test across both nodes
|
- [ ] Step 4 — Scale test across both nodes
|
||||||
- [ ] Step 5 — Docs and history
|
- [ ] Step 5 — Docs and history
|
||||||
@@ -21,3 +21,40 @@ Starting state (read-only PVE API):
|
|||||||
- `vmbr0` on `pv1-2` has no `bridge_vlan_aware`
|
- `vmbr0` on `pv1-2` has no `bridge_vlan_aware`
|
||||||
- template 101 is only on `pv1-1`, with disks `scsi0` + `efidisk0`, both on `local-lvm`
|
- template 101 is only on `pv1-1`, with disks `scsi0` + `efidisk0`, both on `local-lvm`
|
||||||
- `nextid` is 103
|
- `nextid` is 103
|
||||||
|
|
||||||
|
## Steps 1–2 — bridge and template on `pv1-2` (owner, verified 2026-09-30 08:38 CEST)
|
||||||
|
|
||||||
|
The owner made `vmbr0` VLAN-aware on `pv1-2` (`/etc/network/interfaces`, then `ifreload -a`):
|
||||||
|
|
||||||
|
```
|
||||||
|
bridge-vlan-aware yes
|
||||||
|
bridge-vids 2-10
|
||||||
|
```
|
||||||
|
|
||||||
|
This deviates from the plan: `bridge-vids` is `2-10`, not `2-4094`. That's enough for VLAN 4, and
|
||||||
|
any VLAN above 10 on `pv1-2` would need the range widened first.
|
||||||
|
|
||||||
|
Template copy, run on `pv1-1`. A cross-node clone is refused from `local-lvm`, so the copy is a
|
||||||
|
clone on the same node followed by an offline migration:
|
||||||
|
|
||||||
|
```bash
|
||||||
|
qm clone 101 9101 --full 1 --name ubuntu-2404-kube-v1.35.9 --storage local-lvm
|
||||||
|
qm migrate 9101 pv1-2 --with-local-disks
|
||||||
|
ssh root@192.168.0.10 qm template 9101
|
||||||
|
```
|
||||||
|
|
||||||
|
The PVE API shows 9101 on `pv1-2` with `template: 1`, and `scsi0`/`efidisk0` as
|
||||||
|
`local-lvm:base-9101-disk-*`.
|
||||||
|
|
||||||
|
Smoke test ([image-builder-proxmox.md](../image-builder-proxmox.md#smoke-test-of-the-template)) on
|
||||||
|
`pv1-2`, with `TPL=9101 ID=9901`: the VM got a VLAN 4 DHCP address through the guest agent, and was
|
||||||
|
destroyed afterwards. Before running it:
|
||||||
|
- `/root/jan.pub` had to be copied to `pv1-2` first: `scp ~/.ssh/id_ed25519.pub root@192.168.0.10:/root/jan.pub`.
|
||||||
|
- The doc's `ID=9001` now collides with `debian-13-template`, and the snippet ends with
|
||||||
|
`qm destroy $ID`. The snippet now uses 9901 and checks that the ID is free (`a9f5879`).
|
||||||
|
|
||||||
|
Worth noting:
|
||||||
|
- VMIDs are cluster-wide (pmxcfs), which is why the copy needs its own ID. Names don't have to be
|
||||||
|
unique.
|
||||||
|
- The copied `efidisk0` reports `size=528K` (the source says 4M). This doesn't matter: the template
|
||||||
|
boots SeaBIOS.
|
||||||
|
|||||||
Reference in New Issue
Block a user