Networks

Updated Sep 28, 2026

Machines get a real presence on your network through a Linux bridge. Virtainer Free does not run its own DHCP server, NAT, or address management: your existing network keeps doing that job.

The two kinds of network

The management network is how you reach the host itself. There is exactly one, and it is the one that can lock you out.
VM networks are what machines attach to. New machines use the host’s default VM network unless you pick another.

A bridged management network can also carry machines. A management interface that is not bridged cannot, and Virtainer Free refuses rather than quietly breaking your access.

The bridge the host migrates its own address onto is named vmbr0, and it is the default VM network as well. You will see that name in host-side logs and in support output.

Creating a network

The Networks page builds networks from recipes that cover the common shapes:

Recipe	What it gives you
Dedicated	A bridge on its own uplink
Isolated	A segment with no uplink, for machines that should only talk to each other
Bonded uplink	A bridge over bonded interfaces
VLAN segment	A tagged segment on an existing interface

There is also a structured editor for the cases the recipes do not cover, and a topology view showing how interfaces stack up. The management branch is locked by default in that editor, and unlocking it is deliberate.

Changing or deleting a network

Only two things about an existing network can be edited: its name, and the security policy defaults described in Per-machine policy. Reach and uplink are fixed at creation, and the console says so on the edit form. Changing the shape of a network means creating a new one and moving your machines onto it.

Deleting a network is refused while any machine is attached to it. The message names the network by its id and how many machines are attached. That count looks at every network interface on a machine, so a machine whose main interface is on another network still blocks the delete if it has a second interface on this one. Detach that interface, or delete the machine, before you delete the network.

Three more refusals do not depend on that count. The management network cannot be deleted at all. A network that carries the host’s default route cannot be deleted either, so move the host’s address elsewhere first. And a network that snapshots or detached pooled interfaces still depend on is refused until you acknowledge it in the delete confirmation: restoring those snapshots would fail once the network is gone, and a pooled interface on it could not be attached again.

Deleting is confirmed by typing the network’s name. The confirmation names the bridge that will be torn down and states that connected machines lose this network until they are reattached.

The confirmation window

This is what makes management network changes survivable when the configuration is wrong but the host is still talking: leave it alone and it undoes itself.

It is not a general rescue, and the distinction matters. The window cannot recover a change that removes the link itself. If you are editing the bridge that carries the host’s only reachable interface, arrange out-of-band access to the machine, or have someone on site who can power-cycle it, before you apply. Waiting out the five minutes is not a safe plan in that case.

If the change moves the host to a new address, the console reopens a confirmation page at the new address, and you will not have to sign in again to confirm it.

You do not have to wait for the five minutes to run out. The window has two exits: Keep this network finishes the change, and Discard (revert) puts the previous configuration back right away. Either one closes the window, and discarding is the faster route to a second attempt.

Only a change that touches the management network opens a window at all; everything else is applied directly. The host takes one network change at a time. While a window is open, another change that touches the management network is refused because another network change is still inside its confirm window, and editing the topology is refused because a management network change is awaiting keep or discard. Either refusal clears as soon as you resolve the pending change.

A window also freezes the rest of the host: while one is open the host refuses to reboot or shut down, refuses to complete first-run setup, and holds back the automatic reboot after an OS update.

Some changes need explicit acknowledgement even when they are correct: taking over an interface that carries the default route, planning a configuration with no default route at all, or demoting the current management interface.

Per-machine policy

Two controls apply to a machine’s own network attachment:

Anti-spoof restricts a machine to its own address and MAC, so it cannot claim to be something else. Extra source addresses can be allowed explicitly.
Port isolation stops a machine talking directly to its neighbours on the same bridge.

Both can be set on the network as a default and overridden per machine. Each one resolves through three layers, most specific first: the machine’s own override, the default on the network it is attached to, and the host default. The host default is a Host defaults card on the Networks page, below the network list, and the per-machine and per-network selectors name it in place, as in Follow host default (currently On). The console shows the value that is actually in effect and where it came from, so there is no ambiguous inherited setting to guess at.

Both can be changed while the machine runs. A change to a network’s policy is pushed to the machines on it immediately, except where a machine has its own override, which continues to win.

What Free does not do

Cross-host overlay networks, VXLAN creation, and internal NAT private networks are not part of Virtainer Free. Networking spanning more than one host belongs to Virtainer Pro. See Virtainer Pro.