The Virtual Switch: A Step-by-Step Guide to KVM Networking with Netplan

In our journey so far, we have forged the heart of our kingdom—a powerful, secure server. We have also made a critical strategic decision, choosing the path of the fortress by committing to Virtual Machines (VMs) for their unparalleled security and simple, “idiotproof” backup strategy. Our server is a plot of land, and we are ready to build the individual houses that will host our digital services.

But we have a problem. A house with no plumbing or electricity is uninhabitable. Right now, our server—the “Host”—has a single connection to our network. It has its own IP address (10.0.0.50) and can talk to our pfSense router and the internet. But what about the VMs we want to create? How do we give these “Guests” their own network connections? How do we make them first-class citizens in our digital kingdom, each with its own unique address and direct access to the services our network provides?

We cannot simply share the host’s IP address. That would be like an entire neighborhood sharing a single mailbox; the chaos would be unmanageable. We need to give each VM its own place on the network, just as if it were a real, physical computer plugged into a switch.

The solution is to create a virtual network switch inside our host server. This software-defined switch, known as a Network Bridge, is the fundamental piece of infrastructure that makes robust virtualization possible. In this guide, we will dive deep into the “why” and “how” of network bridging. We will then use Netplan, Ubuntu’s modern network configuration tool, to meticulously build this virtual switch, preparing our host to become a true landlord for our future virtual machines.

What is a Network Bridge? The Switch Inside Your Server

To understand a software bridge, it’s best to start with its physical counterpart: a network switch.

You have one of these in your home. It’s a simple box with a number of Ethernet ports. You plug your computer, your printer, and your gaming console into it, and they can all talk to each other and to the router. The switch acts like a local telephone exchange; it learns which device is plugged into which port and intelligently directs traffic only where it needs to go. All devices plugged into the same switch are part of the same local network.

A network bridge does the exact same job, but in software, inside your server’s operating system.

It’s a piece of virtual networking equipment that you create. Here’s how it works:

1. You take your server’s real, physical network card (e.g., enp3s0).
2. Instead of assigning your server’s IP address directly to this physical card, you effectively “unplug” it from the host OS.
3. You then create a new, virtual interface called a bridge (we’ll name ours br0).
4. You “plug” the physical network card into one port of this virtual br0 switch.
5. Finally, you create a virtual network port for your host operating system and “plug” the host itself into another port on the br0 switch. The server’s static IP address (10.0.0.50) is then assigned to this virtual port on the bridge.

The result? The host server now has a virtual switch. Its physical connection to the outside world serves as the “uplink” port. When we create a virtual machine, we can create a virtual Ethernet cable and plug that VM directly into our new br0 switch.

From the perspective of your pfSense router and every other device on your network, your VM will look like just another physical computer. It will ask for its own IP address via DHCP, it can be assigned its own static IP mapping, and you can create specific firewall rules for it in pfSense. This is the cleanest, most secure, and most manageable way to configure networking for virtualization.

A Quick Introduction to Netplan

For many years, network configuration on Ubuntu was handled by editing a file at /etc/network/interfaces. This has been replaced by a more modern, robust system called Netplan.

Netplan is a configuration utility that uses simple, human-readable files written in a format called YAML. You describe the network state you want in a .yaml file, and Netplan takes care of generating the complex configuration for the actual backend software that manages the network (in our case, systemd-networkd).

Why is this better?

• Simplicity: YAML files are much cleaner and easier to read than the old configuration files.
• Error-Checking: Netplan can check your YAML file for syntax errors before you apply it, preventing you from accidentally locking yourself out.
• Consistency: It provides a single, consistent way to configure networking, regardless of the underlying software.

You will find your server’s Netplan configuration file in the /etc/netplan/ directory. It will usually have a name like 00-installer-config.yaml or 50-cloud-init.yaml. This is the file we will be editing.

Preparation and Backup

This is the most critical step. Misconfiguring your network can lock you out of your server’s SSH session. While you can always fix it by plugging in a monitor and keyboard, it’s best to be careful.

1. Log into your server via SSH: ssh your_username@10.0.0.50
2. Identify your Netplan configuration file: ls /etc/netplan/ Take note of the filename (e.g., 00-installer-config.yaml).
3. BACK UP THE FILE! Create a copy of the current, working configuration so you can easily restore it if something goes wrong. sudo cp /etc/netplan/00-installer-config.yaml /etc/netplan/00-installer-config.yaml.bak (Replace 00-installer-config.yaml with your actual filename).
4. Identify your physical network interface name: We need to know the system name for your server’s Ethernet port. ip a Look for the entry that is not lo (the loopback device). It will likely have a name like enp3s0, ens18, or eth0. It should be the interface that currently has the 10.0.0.50 IP address assigned to it. For this guide, we will assume the name is enp3s0.

Creating the New Bridge Configuration

Now we will edit the Netplan YAML file to change our network configuration from a direct assignment to a bridge.

1. Open the file for editing using the nano text editor: sudo nano /etc/netplan/00-installer-config.yaml
2. Analyze the “Before” Configuration: Your current file will look something like this. It assigns the static IP directly to the physical enp3s0 interface.# This is the network config written by the subiquity installer network: ethernets: enp3s0: addresses: - 10.0.0.50/24 routes: - to: default via: 10.0.0.1 nameservers: search: [home.arpa] addresses: [10.0.0.1] version: 2
3. Create the “After” Configuration: We need to completely replace the contents of the file with our new bridge configuration. YAML is very strict about indentation. Use spaces, not tabs, and make sure the alignment is exactly as shown below.Delete all the text in the file and carefully type or paste the following:# This file describes the network interfaces available on your system network: version: 2 ethernets: enp3s0: dhcp4: false dhcp6: false bridges: br0: interfaces: [enp3s0] dhcp4: false dhcp6: false addresses: [10.0.0.50/24] routes: - to: default via: 10.0.0.1 nameservers: search: [home.arpa] addresses: [10.0.0.1]

Deconstructing the New Configuration

Let’s break down exactly what this new file does:

• ethernets:: This section now defines our physical network cards.
  • enp3s0:: We are defining our physical interface.
  • dhcp4: false & dhcp6: false: This is the crucial part. We are telling the system not to try and get an IP address for this physical card. We are detaching it from the host OS’s direct control.
• bridges:: This is a new section where we define our virtual switches.
  • br0:: This is the name we’ve given our new bridge.
  • interfaces: [enp3s0]: This line performs the magic. It tells the system to “plug” our physical enp3s0 card into this br0 bridge.
  • addresses: [10.0.0.50/24]: We are now assigning the server’s static IP address to the bridge interface itself. The host will now communicate through br0.
  • routes: & nameservers:: These sections are the same as before, but they are now applied to the bridge, telling it where to find the router (gateway) and DNS server.

Once you have carefully entered the new configuration, press Ctrl+X to exit nano, then Y to save, and Enter to confirm the filename.

Applying and Verifying the New Configuration

This is the moment of truth. We will use a two-step process to safely apply our new network layout.

1. Generate the configuration: This command will read our YAML file, check it for syntax errors, and create the actual configuration files for the backend. If there’s an indentation error, it will tell you now. sudo netplan generate
2. Apply the configuration: If the generate command completed without errors, you can now apply the new settings. sudo netplan applyYour SSH session may freeze for a moment as the network interfaces are reconfigured. It should come back within a few seconds. If it doesn’t come back after 30 seconds, you may have made a mistake and will need to use the physical console to fix it by restoring your .bak file.
3. Verification: Now, let’s confirm everything worked.
   • Check the interfaces: Run ip a again. You should see a profound change. Your enp3s0 interface should now show that it is UP but it should not have an IP address. You will see a new interface, br0, which does have the 10.0.0.50 IP address. This is proof of success.
   • Check the bridge: To get more details, we can install a small utility. sudo apt update sudo apt install bridge-utils -y Now run: brctl show This command will show you your bridge, br0, and list the interfaces that are “plugged into” it. You should see enp3s0 listed. Later, when we add VMs, their virtual network cards will also appear in this list.
   • Test connectivity: The final test. ping 10.0.0.1 (Ping your pfSense router) ping google.com (Ping an external site) If both of these work, your bridge is fully operational.

Enabling IP Forwarding on the Host

One final but crucial step. For a bridge to pass traffic between the different devices connected to it (like between two future VMs, or from a VM out to the internet via the physical NIC), the Linux kernel must be allowed to forward packets.

1. Enable forwarding in the running kernel: sudo sysctl -w net.ipv4.ip_forward=1
2. Make the change permanent: The command above will be reset on reboot. To make it permanent, we need to edit the sysctl.conf file. sudo nano /etc/sysctl.conf Scroll through the file and look for the line #net.ipv4.ip_forward=1. Remove the # at the beginning of the line to uncomment it. Press Ctrl+X, Y, and Enter to save the file. This setting will now be automatically applied every time the server boots.

What’s Next?

Congratulations. This was one of the most technically demanding steps in our entire journey, and you have successfully re-architected your server’s core networking. Your server is no longer just a single machine; it is now a true hypervisor host, a landlord with a fully-wired apartment block, ready to welcome its first tenants. The virtual switch is on, and the ports are open.

With this foundational networking in place, we are finally ready to install the management tools that will allow us to create and control our fleet of virtual machines. In the next post, “The Control Center: Installing Virtual Machine Manager,” we will install KVM/QEMU, the Libvirt management toolkit, and a lightweight graphical environment that will give us a powerful, user-friendly dashboard for our entire virtualization setup. The real fun is about to begin.