Tigera: Not Every VM Needs to Keep Its IP: Choosing a Network Model for KubeVirt
Your VM estate doesn’t have one network requirement. It has a dozen. Some of those machines were built years ago against an address that is hardcoded in a config file nobody can find. Some sit in a subnet that an upstream firewall rule references by CIDR. Some are perfectly ordinary and would be better off with an address the cluster manages for them.
When those machines move onto Kubernetes, each one gets attached to the network in one of three ways: bridged onto the VLAN it already lives on, routed with an address from a Calico IP pool, or on an overlay. The tempting move is to pick one and apply it to everything, because that’s one decision instead of hundreds.
It’s also the decision that’s most expensive to revisit. The model you choose determines what has to change upstream, what your failure domains look like, how far the design scales, and how much of the migration you can do without a change window on the physical network.
This session works through the three models against the dependencies that actually force the choice.
What you will learn: The Three Attachments, Side by Side — Where the VM’s interface lands in each model, which one gives it an address from your subnet, and where the 802.1Q tag is applied. The Dependency Audit That Picks the Model for You — The five questions that decide this before you do: hardcoded addresses, L2 adjacency, firewall rules written to subnets, MAC-locked licences, and fixed external reachability. What Each Model Costs You Later — Failure domains, scale ceilings, the change-window burden on your network team, and how hard it is to switch models once you’re in production. Where the Address Comes From — Planning Calico IP pools alongside subnets that already exist, so an address conflict doesn’t surface halfway through the migration. What Stays True in All Three — Why label-based policy applies identically whichever model you pick, so the segmentation decision and the network decision stay independent. Where the Packet Actually Goes — The path from a VM to a pod and out to your physical network in each design, and where addressing, routing and NAT differ. Who should attend:- Virtualization practitioners planning a KubeVirt migration who need to know which of their VMs can move on the cluster’s terms and which have dependencies that dictate the design.
- Network engineers who will be asked for a trunk, a VLAN, or a BGP peering, and want to know which of those requests is actually necessary and why.
- Platform engineers running KubeVirt who have been handed a VM estate and need a defensible way to sort it into network models rather than treating every machine the same.
Join us to work through the three ways a VM can attach to a Kubernetes network, and the workload dependencies that decide between them so the model you pick is one you chose rather than one you inherited from a default. You’ll leave with the decision matrix to run against your own migration wave. An educational session on the mechanics, not a product pitch.