Changes To Setting up bridge interface
Not logged in
Home Timeline Files Branches Tags Tickets Wiki Login
Next

Initial version of "Setting up bridge interface"










































































































1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104

+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+

Network bridge allows to bind several network interfaces together, and pass all the packets from one to another.

As separate tap network interface created for each virtual machine, we need bridge to connect all the virtual machines onto virtual network, which would easyly allow to access VMs from host and vice versa, and access one VM from another.

If you just want to download something into VM from outside world, you don't need bridge. Just use 'user' networking and it would be all. You can even access parts of host FS using SMB via user networking, although [vws] doesn't provide easy interface to this feature of QEMU.

But if you want to run web server on VM or use ssh to connect it, bridge is the way to go.

qemu-bridge-helper
==================

As bridge is a network interface, root access is needed to manipulate it. QEMU includes small utility **qemu-bridge-helper** which is designed to be installed setuid root and perform just neccessary operations.

Unfortunately, Debian package doesn't install this utility setuid root. So first thing you'll need to use bridge networking from qemu, started as normal user, is to make this utility setuid root.

    chmod u+s /usr/lib/qemu/qemu-bridge-helper

Bee prepared that after upgrade of the qemu package, suid bit would be lost and your vms would fail to start until you fix it with command above.

Setting up bridge
=================

In any linux system command


    brctl addbr vm0

is used to create bridge interface vm0. After that this interface can be configured via **ifconfig** or **ip** command just like any other interface, **dnsmasq** could be run on it and **iptables** rules could be set.

But different linux distributions have different ways to automate this task so 
interface would be created at startup.
 
Debian and Ubuntu
-----------------

You should add following to your /etc/network/interfaces:

    auto vm0
    iface vm0 inet static
         address 192.168.9.1
         network 192.168.9.255
         netmask 255.255.255.0
         bridge_ports none

(of course you can peek any number from 0 to 255 instead of 9 here for third octet of the IP. You can also use addresses from 10.0.0.0/8 or 172.16.0.0/12 instead of 192.168.0.0/16)

Interface created this way would be totally isolated from outside world. This is probably not what you want, because you'll at least need to access software updates for your guest os. So, add following line:

    post-up iptables -t nat -A POSTROUTING -s 192.168.9.0/24 -j MASQUERADE

and don't forget to enable ipv4 forwaring in the kernel.

Really it is enough for bridge configuration, if you don't mind to setup static IP for each of your VM manually. But using dnsmasq would save you great deal of effort if you have more then 2-3 virtual machine.

RHEL, CentOS etc
----------------

Create file **ifcfg-vm0** in the /etc/sysconfig/network-scripts with following content

     TYPE=Brigde
     ONBOOT=yes
     DEVICE=vm0
     IPADDR0=192.168.9.1
     NETMASK0=255.255.255.0

dnsmasq
=======

**dnsmasq** is a small dhcp and DNS server. If you would run it, it would act as caching DNS for your host machine and also provide IP Addresses for virtual machines and resolve their names.

You need to be sure that it servers DHCP only to your virtual bridge network, not to the physical network which connects you to internet, or it would conflict with dhcp server on your router and cause a mess.

So, you should have at least following lines in your dnsmasq.conf

    no-dhcp-interface=eth0
    domain=local.vm,192.168.199.0/24
    dhcp-range=192.168.9.10,192.168.9.150,12h

First line specifies, that your ethernet interface shouldn't be served DHCP by dnsmasq. If your primary interface is wlan0 list it as no-dhcp-interface instead. If you have more than one physical network interface, repeat no-dhcp-interface line for each of them.

Second line tells dnsmask to tell virtual machines that they have local.vm domain (you may pick any other if yo want)

And third line specifies range of addresses to give virtual machines, and time for which it this address is valid (12 hours). 

Also add 192.168.9.1 into your /etc/hosts with name of you host and local.vm domain, and make sure that your resolv.conf points to local host (0.0.0.0 or 127.0.0.1 as nameserver) and lists local.vm domain in search statement.

With this setup you'll be able to access all your virtual machines using their hostnames, set up during guest OS installations. 

When requesting IP from DHCP server they'll tell their hostnams, and dnsmasq would add DNS records to local.vm domain for each assigned address.

dnsmasq would also read your /etc/hosts and create dns records based on addresses and names listed here.

If your machine gets primary address and DNS server via DHCP, consult your distribution documentation, how to make your DHCP client to not pollute your resolv.conf and tell addresses of external DNS servers dnsmasq instead.

In Debian you'll need to install resolvconf package to simplify this task.




 

   














Fossil version [3c53b6364e] 2023-02-26 19:24:24