Local NI -- VM deployment trace (confirmed live)

← Back to Network Instance

This page documents a full confirmed live trace of deploying a VM into a Local (NATed) Network Instance on EVE-K, including all host-side and k3s-side observations.

Device: c86eddc2-9a2f-4a0e-a761-25e70e7cbb89
App Instance UUID: 68766b45-9eeb-45a8-819f-26d1f60ca3d0
Network Instance UUID: d07fe671-87bc-4576-8031-bde9b42bf90f (Local type, eth0)
Image volume: e9579d78-99f3-4b8f-9c16-3adbb32b2fd8 (20Gi Longhorn)

16:12:28 → Pending    VMI created by zedkube in k3s
16:12:30 → Scheduling KubeVirt scheduler running
16:12:48 → Scheduled  placed on node tf-demo-adv-en-1
16:12:52 → Running    VM booted

Total time: 24 seconds from VMI creation to running.

cat /run/zedrouter/NetworkInstanceStatus/d07fe671-87bc-4576-8031-bde9b42bf90f.json | \
  jq '{Activated, BridgeName, BridgeIPAddr, BridgeNum, MirrorIfName, Vifs, IPAssignments}'

IP assignments confirmed:

The VM's virtual interface is named nbu1x1. EVE's VIF naming scheme:

n  b  u  1  x  1
|  |  |  |  |  |
|  |  |  |  |  +-- app number
|  |  |  |  +----- separator
|  |  |  +-------- bridge number (matches bnX)
|  |  +----------- unit
|  +-------------- bridge
+----------------- network

So nbu1x1 = network bridge unit, bridge 1, app 1.

brctl show

bridge name   bridge id           STP   interfaces
bn1           8000.00163ec2c101   no    nbu1x1

bn1 has nbu1x1 as its only interface when one VM is attached. Before the VM was deployed, bn1 existed but had no interfaces (state DOWN). After VM deployment, nbu1x1 appears in the bridge and state becomes UP.

cat /run/zedrouter/dnsmasq.leases/bn*

1781889194  02:11:22:33:44:55  10.33.0.20  68766b45-9eeb-45a8-819f-26d1f60ca3d0  *

iptables -t nat -L POSTROUTING-apps -n | grep d07fe671

MASQUERADE  all  --  10.33.0.0/24  0.0.0.0/0
  /* SNAT traffic from NI d07fe671-... leaving via port eth0.253 */

Key finding: The uplink is eth0.253 not bare eth0 – this NI uses a VLAN subinterface (VLAN ID 253) on eth0 as its uplink.

cat /run/zedrouter/AppNetworkStatus/68766b45-9eeb-45a8-819f-26d1f60ca3d0.json | jq

Key confirmed fields:

enp1s0                          inside the VM (guest interface)
    |
nbu1x1                          EVE VIF on host (in bridge bn1)
    |
pod6c270ef2f25                  Multus pod interface (in virt-launcher netns)
    |
bn1  (10.33.0.1/24)             Linux bridge -- gateway for 10.33.0.0/24
    |
eth0.253                        VLAN subinterface (VLAN ID 253) -- uplink
    |
eth0                            Physical NIC
    |
MASQUERADE (SNAT)               10.33.0.0/24 → external network

cat /run/domainmgr/DomainStatus/68766b45-9eeb-45a8-819f-26d1f60ca3d0.json | \
  jq '{State, VifList, BootTime}'

The k3s VMI spec is identical to the Switch NI VMI spec. Kubernetes has no knowledge of which NI type is being used. All NI-type logic is handled entirely by the eve-bridge CNI plugin at the host level.

networks:
- multus:
    networkName: network-instance-attachment   # same bootstrap NAD as Switch NI
  name: net1

interfaces:
- bridge: {}                                   # same bridge mode as Switch NI
  macAddress: "02:11:22:33:44:55"              # same EVE-assigned MAC format
  name: net1
  podInterfaceName: pod6c270ef2f25
  linkState: up
  infoSource: domain, multus-status            # confirmed by both KubeVirt and Multus

The VMI spec is identical for both NI types. The NI type is completely opaque to Kubernetes. The eve-bridge CNI plugin resolves all NI-specific behaviour at runtime on the host.

# NI status -- VIFs and IP assignments
cat /run/zedrouter/NetworkInstanceStatus/<ni-uuid>.json | \
  jq '{Activated, BridgeName, BridgeIPAddr, Vifs, IPAssignments}'
 
# App network status -- full VIF chain
cat /run/zedrouter/AppNetworkStatus/<app-uuid>.json | jq
 
# DHCP leases -- what IP did the VM get
cat /run/zedrouter/dnsmasq.leases/bn*
 
# Bridge -- confirm VIF is attached
brctl show bn1
 
# NAT rules -- confirm MASQUERADE
iptables -t nat -L POSTROUTING-apps -n | grep <ni-uuid>
 
# Domain status -- EVE's view of the running VM
cat /run/domainmgr/DomainStatus/<app-uuid>.json | jq '{State, VifList, BootTime}'
 
# k3s -- VMI
kubectl get vmis -n eve-kube-app
kubectl get vmi <name> -n eve-kube-app -o yaml

• pkg/pillar/cmd/zedrouter/ – zedrouter VIF and bridge management
• pkg/pillar/cmd/domainmgr/ – domainmgr VIF list and domain status
• pkg/kube/eve-bridge/ – eve-bridge CNI plugin
• lf-edge/eve on GitHub