fix(unifi): pin the MAC — an unpinned MAC is why the guest keeps losing its IP
Operator set console-password in the SOPS secret (installer-url deliberately left as REPLACE-ME, which install-uos handles by printing 'not set yet' and exiting 0; the uosserver guard exits before it is even read). Root cause of the lost address, from evidence rather than inference. KubeVirt generates a fresh MAC per VMI when none is pinned. cloud-init writes /etc/netplan/50-cloud-init.yaml matching the MAC it saw, and will not rewrite it while the NoCloud instance-id is unchanged — and that instance-id is domain.firmware.uuid, stable across restarts by design. So every VMI recreation handed the guest a MAC its retained netplan did not match, leaving enp1s0 administratively DOWN, never even attempting DHCP. What the 2026-09-12 boot log shows, and why it fits: cloud-init's own device table reads 'enp1s0 | Up: False | Address: .'; there are no apt failures because the per-instance modules were skipped; yet UOS is installed (6.3 GB of 40 GB) and qemu-guest-agent answers — both of which required working network on an EARLIER VMI. The MAC is identical between the current VMI status and that boot log, so it did not change on this boot; the mismatch is against a netplan written under a previous incarnation. Pinned to the MAC the current VMI already holds, so nothing changes for this guest. Combined with the instance-id bump already merged, the next restart re-runs cloud-init, rewrites netplan against a MAC that is now permanent, and the interface should come up — and the console password is in place as the fallback if it does not. Still unverified from outside: the netplan file's actual contents. That needs the console the operator can now reach. Co-Authored-By: Claude Opus 5 <[email protected]>
This commit is contained in:
1 parent
05881d5a6a
commit
14d5ccbadd
2 files changed
+23
-9
No files matched your search
@@ -95,8 +95,22 @@ spec:
|
||||
disk:
|
||||
bus: virtio
|
||||
interfaces:
|
||||
# MAC PINNED 2026-09-18, and this is a root-cause fix, not cosmetics.
|
||||
# KubeVirt generates a fresh MAC for every VMI when none is pinned. cloud-init writes
|
||||
# /etc/netplan/50-cloud-init.yaml with a `match` on the MAC it saw, and it will NOT rewrite
|
||||
# that file while the NoCloud instance-id is unchanged — and the instance-id here is
|
||||
# domain.firmware.uuid, which is stable across restarts by design. So each VMI recreation
|
||||
# handed the guest a NEW MAC that the retained netplan did not match, leaving enp1s0
|
||||
# administratively DOWN with no address and no DHCP attempt.
|
||||
# That is exactly what the evidence shows for the boot of 2026-09-12: cloud-init's own
|
||||
# device table reports `enp1s0 | Up: False | Address: .`, no apt failures are logged
|
||||
# (because the per-instance modules were skipped), yet UOS is installed and
|
||||
# qemu-guest-agent runs — both of which required a working network on an EARLIER VMI.
|
||||
# Pinning the MAC to the value the current VMI already holds makes the guest's netplan
|
||||
# match permanently, so this cannot recur on the next recreation.
|
||||
- name: default
|
||||
masquerade: {}
|
||||
macAddress: a6:d7:c0:b3:72:fa
|
||||
# Declaring ports on a masquerade iface (a) restricts pod->VM forwarding to exactly
|
||||
# these and (b) surfaces them as containerPorts on the virt-launcher pod so the
|
||||
# LoadBalancer Services + CiliumNetworkPolicy ingress can target/match them.
|
||||
|
||||
@@ -5,8 +5,8 @@ metadata:
|
||||
namespace: unifi
|
||||
type: Opaque
|
||||
stringData:
|
||||
installer-url: ENC[AES256_GCM,data:CGCWLMiHlF57/w==,iv:/tilBVekwbHkAjSBi5UKUljfaqPo/hXhNqMYS4LY/kA=,tag:b7SeEM30ua/HvutGHYEdXg==,type:str]
|
||||
console-password: ENC[AES256_GCM,data:gkPbmZ4g7he2WA==,iv:T9PUgAmOsrt4LUB+5vXBr9ctOPsXP5z/vMWr2ls+3ko=,tag:83HDr4kCrUF7u83fpIkm4A==,type:str]
|
||||
installer-url: ENC[AES256_GCM,data:2sdkFOPxQ4ZrBQ==,iv:OnEip59rvdSulZASp5J8Gj2M55wuYD9TcACd63lqwBA=,tag:hJ437ZbPEnee/t48Sm6eBg==,type:str]
|
||||
console-password: ENC[AES256_GCM,data:XwTpKiqnzBz/ydaa+Mbv,iv:A2sWqkDaM+GD4e0t8wKC75UM15WprYmNHNEpNyb+m/c=,tag:VKlGvpyRIQ4dqcgWTpuqiQ==,type:str]
|
||||
sops:
|
||||
kms: []
|
||||
gcp_kms: []
|
||||
@@ -16,14 +16,14 @@ sops:
|
||||
- recipient: age175l8mdpdfu7hq0aml3exs3gykarwjmuvr23sq56s3wjejnyk44wsp4mfzg
|
||||
enc: |
|
||||
-----BEGIN AGE ENCRYPTED FILE-----
|
||||
YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IFgyNTUxOSBIV3hvNUVRTWxINmtaQkp5
|
||||
a0VkYitYNHFWUGRhYncxVXl4MFdET1VmQTJZCnVXaDhaRHpQVkdHWG4xUElqRFNG
|
||||
VUhPU3dpa0VMWGxQdUxGeDZuNFZWVm8KLS0tIEFMY2RNVDBvMG51SkhqVzlXUjRR
|
||||
TG9kcHdSTU5QOGpnLzkyVW9hUWJLem8KW536eEsviMq5/uyg3/RT/PrEgr4PBL3E
|
||||
yNemOTU76DdU81/neHb/6NVWT44ffLoCltgSrCQ0ieBwDAorjQ3bEg==
|
||||
YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IFgyNTUxOSBRYlFOZ25ycWRCWUpyMjdQ
|
||||
OFMrWUNyMWJOVlF3MU9DY1phWnhZQ1YyeFVZCkc0WTVia2RyTkhreFYyS3Bya08r
|
||||
bWwvMWt5a3E5OXh5b0xIT0FKQUE0d0UKLS0tIDJSaEc5YndEOFgrbkhlZm5TRVI5
|
||||
RVo1bWwxL0lCR2NpUENUdGovREF1K1UKnJHnFsUkg4drovNCB5xSqVUaQF48b1No
|
||||
tI5+ABiIv3fjuuf+hW7lOm7M1F3jAwlNAgbe8wBqS2C9Wx5MV1kGDA==
|
||||
-----END AGE ENCRYPTED FILE-----
|
||||
lastmodified: "2026-09-19T01:51:00Z"
|
||||
mac: ENC[AES256_GCM,data:yKGOdLKnIUUeSyJuzyp4CiJFhTyIJv6S8PTEdnioCpeSoRpptWYQIKR8BUrYx1/4NnghvOEyS5o0nRT56dq7vf2G+CoRf03/alDW/YHUjkAfIRjorPCO638mjdIPDytfsTBOyBXnjzjMlhHwoDjHskk+J66Qm42xFd476w9cYig=,iv:M1SwKW2ZUehklgUP+n3fefb2XoDDPBs5HnTklVh3KwM=,tag:q6eoA+pdHnwWKxQODCN7jQ==,type:str]
|
||||
lastmodified: "2026-09-19T02:30:07Z"
|
||||
mac: ENC[AES256_GCM,data://GkUcyrDWgcNE769Q37CT95NQYQ6KVHN31+ZQBu+S1FD1Gk7GCyHyaGPRzUjcQk60WgD12brLwr9F0e021L40NTK/ZHvsnBtFd8WpydUNLOuCitJShlMX1/VsXZvP0FHeV0/PZlb1Qebzunhgkwt8B4FUJ0D+yycNzlDrFz1Ko=,iv:iVJLPIKs4inK+dzDd06ewC8euHXMwcmwIip4ntnEmp4=,tag:X93BJEVMrIlYoQO3KiZJ0g==,type:str]
|
||||
pgp: []
|
||||
encrypted_regex: ^(data|stringData)$
|
||||
version: 3.9.4
|
||||
Reference in new issue
Block a user