Container vs VM Networking

LXC containers and KVM virtual machines both connect cleanly to a Proxmox bridge, but they do it through different abstractions.

Container Networking (LXC)

LXC containers share the host's Linux kernel but get their own isolated network namespace.

Container has:
|- Virtual ethernet interface: eth0
|- IP address: 192.168.1.25 (assigned by DHCP from router)
`- Gateway: 192.168.1.1 (ASUS Router)
 
Connection path:
Container eth0 <-> veth pair <-> vmbr0 bridge <-> physical ethernet

From the LAN's perspective, the container behaves like a normal machine on the network.

VM Networking (KVM)

VMs get a fully emulated virtual network card, usually virtio for better performance. The path is similar to containers.

VM virtual NIC <-> vmbr0 bridge <-> physical ethernet

VMs have more isolation because they emulate a full machine, but that comes with more overhead than a container.

That tradeoff is exactly why small Kubernetes clusters in this lab live in VMs rather than in host-side container experiments. Kubernetes On Proxmox With k3s uses full guest boundaries so the cluster can be snapshotted, rebuilt, and upgraded without turning the hypervisor into part of the control plane.

Performance Comparison

Native Proxmox host ping to router:   < 1 ms
Container ping to router:             < 1 ms
VM ping to router:                    < 1 ms

For typical homelab services, the networking difference is negligible. The real decision usually comes down to isolation, operating system requirements, and operational overhead rather than raw latency.