Score:1

Can I have my KVM guests on the same subnet as the host?

sk flag

Using virtual network "default" I get the guests on their own subnet, NAT'ed to the host's subnet.

Using a separate bridge, it seems possible to have guests on the same subnet as the host, but apparently this requires a dedicated physical nic on the host?

I have experimented with macvtap vepa or bridge, but could not get a link this way.

Is it possible to have the guests appear just like any other physical machine on the same subnet as the host? And if so, how? I need this as my application uses broadcast communication.

I am using QEMU/KVM, on rhel and ubuntu. Guests are also rhel or ubuntu. I define/manage the VMs using virt-install, virsh (and virt-manager for testing/debugging). The server does not have any extra nic's available for these purposes, only the one used by the host itself.

Michael Hampton avatar
cz flag
Yes, of course you can do this, and you already have the NIC! See for instance https://access.redhat.com/labs/kvmbridgeconfiguration/ or https://access.redhat.com/solutions/18734
Score:2
br flag

Process on Ubuntu 20.04:

Set up the logical network bridge on the host

Create /etc/netplan/01-kvmbridge.yaml. Example:

network:
  ethernets:
    enp2s0f0:
      dhcp4: false
  bridges:
    br0:
      interfaces: [enp2s0f0]
      dhcp4: true
      mtu: 1500
      parameters:
        stp: true
        forward-delay: 15

Notes: NIC name will differ depending on driver. Address assignment doesn't have to be by DHCP.

Run sudo netplan try to test the config and sudo netplan apply to apply it once you're satisfied it works. Note that changing a network config over ssh may not be a good idea.

Tell KVM how to access the connection

Create a file ~/kvmbridge.xml with the following contents:

<network>
  <name>host-bridge</name>
  <forward mode="bridge"/>
  <bridge name="br0"/>
</network>

Enable the bridge:

virsh net-define ~/kvmbridge.xml
virsh net-start host-bridge
virsh net-autostart host-bridge

You should now be able to select the network host-bridge for your VMs to have them coexist on the same network as the host.

Score:1
dj flag

We want to have the QEMU/KVM guest VM to be on the same network subnet as the host.

In this example, the host IP on the network has IP address 192.168.0.10. The host only has one and only one NIC.
Disconnect or turn off (the best way is to delete) the existing wired network connection.
This is very important so that the existing connection doesn't interfere with the following setup.

The setup is by using nmcli (command-line tool for controlling NetworkManager) and brctl (ethernet bridge administration) A handy tool to install is nm-connection-editor which is great for setting up or deleting connections.
One can always create a bridge with brtcl command to test before committing with nmcli. In the following example the only use of brtcl command is to show the bridge connections, and not creating the bridge for testing. We are creating, hence committing, the bridge connection by using nmcli.

sudo nmcli con show
NAME    UUID                                  TYPE    DEVICE
virbr0  c42932ae-be14-4b8e-9c70-69868d093483  bridge  virbr0

We ignore virbr0 as it was created by VirtualBox and create a new one

sudo brctl show
bridge name     bridge id               STP enabled     interfaces
virbr0          8000.52540066413b       yes

Again, in this case we are ignoring virbr0 as it is already created by VirtualBox.

Add a new bridge interface on host machine call it br0:

sudo nmcli con add type bridge ifname br0
Connection 'bridge-br0' (0ac8ba53-3ae8-4241-b464-ec0671aa0239) successfully added.

ip a
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether d8:bb:c1:47:1b:bb brd ff:ff:ff:ff:ff:ff   <---
    altname enp5s0
6: br0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether 66:bb:79:6b:bb:67 brd ff:ff:ff:ff:ff:ff   <---

Attach the newly added bridge br0 to physical interface on host, in this case eth1:

sudo nmcli con add type bridge-slave ifname eth1 master br0
Connection 'bridge-slave-eth1' (4696cbda-1002-469c-9893-c085e726ebd5) successfully added.

sudo nmcli con show
NAME               UUID                                  TYPE      DEVICE 
bridge-br0         0ac8ba53-3ae8-4241-b464-ec0671aa0239  bridge    br0   <---
bridge-slave-eth1  4696cbda-1002-469c-9893-c085e726ebd5  ethernet  eth1   <---
virbr0             c42932ae-be14-4b8e-9c70-69868d093483  bridge    virbr0

ip a
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether d8:bb:c1:47:1b:bb brd ff:ff:ff:ff:ff:ff   <---
    altname enp5s0
6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether d8:bb:c1:47:1b:bb brd ff:ff:ff:ff:ff:ff   <---
    inet 192.168.0.10/24 brd 192.168.0.255 scope global dynamic noprefixroute br0
       valid_lft 86071sec preferred_lft 86071sec
    inet6 fe80::291e:4838:6d3b:6620/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
   

Notice that br0 is now attached to the physical interface *eth1.
This will also reflect in 'brctl show' :

sudo brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.d8bbc1471bdb       yes             eth1   <---
virbr0          8000.52540066413b       yes

To check with ip command that br0 is a bridge connection:

ip link show type bridge
6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether d8:bb:c1:47:1b:bb brd ff:ff:ff:ff:ff:ff

To check with IP command the master to br0:

ip link show master br0
2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP mode DEFAULT group default qlen 1000
    link/ether d8:bb:c1:47:1b:bb brd ff:ff:ff:ff:ff:ff
    altname enp5s0

Configure the Virtual Machine Manager (QEMU/KVM) to use Network Source as 'Bridge device' and 'Device name': br0

Start the guest VM and run 'ip a' command:

VirtMachine1:~> ip a
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:e8:ba:ce brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.192/24 brd 192.168.0.255 scope global dynamic noprefixroute enp1s0
       valid_lft 86392sec preferred_lft 86392sec
    inet6 fe80::5054:ff:fee8:bace/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

Hope this helps.

Score:0
jp flag

Thank you so much. Just started with KVM. This worked very well and just wondering why this isn't more documented as it should be a very regular use case for home or even in enterprises where the DHCP server is a seperate device (like a router in the home) and you wish to access it (as a webserver for example) from other computers on the network.

Hereby would like to add some things for those to complete the procedure based on my experience:

  1. after enablig the bridge as above, reboot the server. Notice that the physical network card will not be accessible (e.g by SSH) anymore from the network. The new (bridge) interface "br0" will and will have an IP address different from the network card.

  2. To change the VM (here ubuntu-guest) using the bridge:

virsh edit ubuntu-guest

just change only the source to br0

<interface type='bridge'> <mac address='52:54:00:f9:71:d5'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'> </interface>

  1. (re)start the VM

  2. To find the IP of the VM, use virsh console . Then run ifconfig to find it's IP (I have not found another way to find the VM's IP)

BTW. regarding changing the network config over SSH, what I used is a "NULL modem" serial connection between the the server and the client.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.