Keying the network-data on instanceProfile reached every VM that never
set the field, because the profile defaults to ubuntu whatever image
the disk holds. The sysconfig, NetworkManager and eni renderers turn
each match stanza into an interface literally named after the netplan
ID, so a non-netplan guest left on the default profile would lose the
DHCP it gets today. A VM with neither cloudInit nor sshKeys would also
gain a cloud-init disk on upgrade, and KubeVirt's NoCloud instance-id
is new to that guest, so its next boot would regenerate host keys as a
first boot.
The configuration also shadows a static NIC set up through netplan:
netplan emits one networkd file per ID, networkd applies only the first
file in lexical order that matches a link, and 10-netplan-cozy-en sorts
before the file for enp2s0. The external-VLAN recipe claimed otherwise.
An explicit netplanDhcp value, off by default, leaves every existing
VM rendering exactly as before and lets the documentation say when not
to turn it on.
Assisted-by: LLM
Signed-off-by: Mattia Eleuteri <mattia@hidora.io>
A netplan guest configures only the interface cloud-init's fallback
configuration covers, and keeps none of the search domains DHCP offers
it, so two things the platform already puts on the wire never reach it.
virt-launcher runs a DHCP server on every bridge-bound interface,
secondary ones included, yet a VM joined to a VPC subnet leaves that
interface inert for want of a client asking. The same server advertises
the launcher pod's search domains as option 119, which systemd-networkd
discards because UseDomains= defaults to no, and a cluster domain under
.local then falls through to the mDNS exclusion in resolved and answers
REFUSED.
The virtual-machine chart carried a network-data template for the first
of those, gated on systemDisk.image. Splitting that chart into vm-disk
and vm-instance removed the template along with the field it read, and
neither came back.
Matching en* and eth* rather than naming interfaces by index keeps the
configuration correct whatever the guest enumerates its NICs as, which
is where the previous template was fragile.
Assisted-by: LLM
Signed-off-by: Mattia Eleuteri <mattia@hidora.io>
Multus-backed NetworkAttachmentDefinitions delegate to the upstream
containernetworking reference plugins (bridge, macvlan, ipvlan, ...),
and nothing guarantees a node has them in the directory Multus
searches. On k3s they live under /var/lib/rancher/k3s/data/cni while
Multus and Cilium install into /opt/cni/bin, so a bridge-type NAD fails
there with `failed to find plugin "bridge" in path [/opt/cni/bin]`.
Bundle 14 of the release's plugins into the multus image and add an
install-cni-plugins init container that installs them into the host
/opt/cni/bin, mirroring the existing install-multus-binary container.
loopback, dhcp, tap and dummy are left out; the Dockerfile records why.
Gate it on a new chart value, stageCniPlugins, resolved per bundle and
on for both. Talos bundles only bridge, firewall, flannel, host-local,
loopback and portmap, so the other ten are missing there exactly as on
generic Linux; the four that overlap are rewritten with the same
upstream version, v1.9.1 on both sides, rather than an older one. A
marker in the image Dockerfile records the Talos release that pin was
compared against, and a test holds it to the release the platform
ships. multus therefore moves out of system.common-packages into the
two variant branches, the way linstor already does for talos.enabled.
networking.stageCniPlugins overrides the variant default in either
direction.
Where staging is on the install is unconditional: a plugin is replaced
on every pod recreation, not only when the destination is missing. A
destination that is already a directory is reported and left alone,
since replacing it is not something this can do safely. Turning the
value off afterwards does not undo it; nothing here removes or
restores a plugin.
The container is not privileged and takes no mount propagation. It
runs in the spc_t SELinux domain, without which an enforcing node
refuses the write. Each plugin is installed under a temporary name and
swapped in with a rename: /opt/cni/bin is shared with cilium and
kube-ovn. The plugin tarball is checksummed before extraction.
A plugin that cannot be installed is reported on stderr and to
/dev/termination-log, and the container still exits 0: Multus stays the
node's primary CNI and nothing removes its config, so an init container
that never completes would leave the shim with no daemon behind it.
The manifest change lives in customize-deployment.patch so it survives
make update.
BREAKING CHANGE: enabling stageCniPlugins replaces reference CNI
plugins in /opt/cni/bin on existing nodes, Talos included -- four of the
names it writes are ones the Talos node image also carries. Opt out
before upgrading: declining afterwards does not restore what was
replaced.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Add a guide for bridging a vm-instance VM onto a physically-routed VLAN
via a Linux bridge and a bridge-type NetworkAttachmentDefinition. The
overlay-only default does not cover the case where a VM must share a
broadcast domain with external hardware and take an address from that
VLAN's subnet.
Explain why macvlan is incompatible with KubeVirt bridge binding (macvlan
demultiplexes ingress by the child MAC while bridge binding puts the
guest MAC on the wire, so replies are dropped) and why a Linux bridge
works, then walk through the host bridge, the NAD, and assigning a static
guest address through cloud-init. Cover the dual-homed NIC layout, the
absence of networkData, and the post-recreate ARP staleness.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Mattia Eleuteri