Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

11.2. Red Hat Enterprise Linux 5.0 laptop network configuration


This section describes manually adding network bridges. This procedure is not required or recommended for all versions of Red Hat Enterprise Linux newer than version 5.0. For newer versions use "Virtual Network" adapters when creating guests in virt-manager. NetworkManager works with virtual network devices by default in Red Hat Enterprise Linux 5.1 and newer.
An example of a virsh XML configuration file for a virtual network device:
<interface type='network'>
	<mac address='AA:AA:AA:AA:AA:AA'/>
	<source network='default'/>
	<target dev='vnet0'/>
	<model type='virtio'/>
In xm configuration files, virtual network devices are labeled "vif".
The challenge in running the Xen hypervisor on a laptop is that most laptops will connected to the network via wireless network or wired connections. Often these connections are switched multiple times a day. In such an environment, the system assumes it has access to the same interface all the time and it also can perform ifup or ifdown calls to the network interface it is using. In addition wireless network cards do not work well in a virtualization environment due to Xen's (default) bridged network usage.
This setup will also enable you to run Xen in offline mode when you have no active network connection on your laptop. The easiest solution to run Xen on a laptop is to follow the procedure outlined below:
  • You will be configuring a 'dummy' network interface which will be used by Xen. In this example the interface is called dummy0. This will also allow you to use a hidden IP address space for your guests.
  • You will need to use static IP address as DHCP will not listen on the dummy interface for DHCP requests. You can compile your own version of DHCP to listen on dummy interfaces, however you may want to look into using dnsmasq for DNS, DHCP and tftpboot services in a Xen environment. Setup and configuration are explained further down in this section/chapter.
  • You can also configure NAT and IP masquerading in order to enable access to the network from your guests.
Configuring a dummy network interface

Perform the following configuration steps on your host:

  1. Create a dummy0 network interface and assign it a static IP address. In our example I selected to avoid routing problems in our environment. To enable dummy device support add the following lines to /etc/modprobe.conf:
    alias dummy0 dummy
    options dummy numdummies=1
  2. To configure networking for dummy0, edit or create /etc/sysconfig/network-scripts/ifcfg-dummy0:
  3. Bind xenbr0 to dummy0, so you can use networking even when not connected to a physical network. Edit /etc/xen/xend-config.sxp to include the netdev=dummy0 entry:
    (network-script 'network-bridge bridge=xenbr0 netdev=dummy0')
  4. Open /etc/sysconfig/network in the guest and modify the default gateway to point to dummy0. If you are using a static IP, set the guest's IP address to exist on the same subnet as dummy0.
  5. Setting up NAT in the host will allow the guests access Internet, including with wireless, solving the Xen and wireless card issues. The script below will enable NAT based on the interface currently used for your network connection.
Configuring NAT for guests

Network address translation (NAT) allows multiple network address to connect through a single IP address by intercepting packets and passing them to the private IP addresses. You can copy the following script to /etc/init.d/xenLaptopNAT and create a soft link to /etc/rc3.d/S99xenLaptopNAT. This automatically starts NAT at boot time.


The script below may not work well with wireless network or NetworkManager due to start-up delays. In this case run the script manually once the machine has booted.

export PATH
GATEWAYDEV=`ip route | grep default | awk {'print $5'}`
iptables -F
case "$1" in
	if test -z "$GATEWAYDEV"; then
	echo "No gateway device found"
	echo  "Masquerading using $GATEWAYDEV"
	/sbin/iptables -t nat -A POSTROUTING -o $GATEWAYDEV -j MASQUERADE
	echo "Enabling IP forwarding"
	echo 1 > /proc/sys/net/ipv4/ip_forward
	echo "IP forwarding set to `cat /proc/sys/net/ipv4/ip_forward`"
	echo "done."
echo "Usage: $0 {start|restart|status}"
Configuring dnsmasq for the DNS, DHCP and tftpboot services

One of the challenges in running virtualization on a laptop (or any other computer which is not connected by a single or stable network connection) is the change in network interfaces and availability. Using a dummy network interface helps to build a more stable environment but it also brings up new challenges in providing DHCP, DNS and tftpboot services to your guest virtual machines. The default DHCP daemon shipped with Red Hat Enterprise Linux and Fedora Core will not listen on dummy interfaces, and your DNS forwarded information may change as you connect to different networks and VPNs.

One solution to the above challenges is to use dnsmasq, which can provide all of the above services in a single package, and also allows you to configure services to be available only to requests from your dummy interface. Below is a short write up on how to configure dnsmasq on a laptop running virtualization:
  • Get the latest version of dnsmasq from here.
  • Documentation for dnsmasq can be found here.
  • Copy the other files referenced below from and grab the file dnsmasq.tgz. The tar archive includes the following files:
    • nm-dnsmasq can be used as a dispatcher script for NetworkManager. It will be run every time NetworkManager detects a change in connectivity and force a restart or reload of dnsmasq. It should be copied to /etc/NetworkManager/dispatcher.d/nm-dnsmasq
    • xenDNSmasq can be used as the main startup or shutdown script for /etc/init.d/xenDNSmasq
    • dnsmasq.conf is a sample configuration file for /etc/dnsmasq.conf
    • dnsmasq is the binary image for /usr/local/sbin/dnsmasq
  • Once you have unpacked and built dnsmasq (the default installation will be the binary into /usr/local/sbin/dnsmasq) you need to edit your dnsmasq configuration file. The file is located in /etc/dnsmaqs.conf.
  • Edit the configuration to suit your local needs and requirements. The following parameters are likely the ones you want to modify:
    • The interface parameter allows dnsmasq to listen for DHCP and DNS requests only on specified interfaces (such as dummy interfaces). Note that dnsmasq cannot listen to public interfaces as well as the local loopback interface simultaneously. Add another interface line for more than one interface. interface=dummy0 is an example which listens on the dummy0 interface.
    • Modify dhcp-range to enable the integrated DHCP server. You will need to supply the range of addresses available for lease and optionally a lease time. If you have more than one network, you will need to repeat this for each network on which you want to supply DHCP service. An example would be (for network 10.1.1.* and a lease time of 12 hours): dhcp-range=,,,12h
    • Modify dhcp-option to override the default route supplied by dnsmasq, which assumes the router is the same machine as the one running dnsmasq. An example would be dhcp-option=3,
  • After configuring dnsmasq you can copy the script below as xenDNSmasq to /etc/init.d
  • If you want to automatically start dnsmasq during system boot, you should register it using chkconfig(8):
    chkconfig --add xenDNSmasq
    Enable it for automatic startup:
    chkconfig --levels 345 xenDNSmasq on
  • To configure dnsmasq to restart every time NetworkManager detects a change in connectivity you can use the supplied script nm-dnsmasq.
    • Copy the nm-dnsmasq script to /etc/NetworkManager/dispatcher.d/
    • The NetworkManager dispatcher will execute the script (in alphabetical order if you have other scripts in the same directory) every time there is a change in connectivity.
  • dnsmasq will also detect changes in your /etc/resolv.conf and automatically reload them (if you start up a VPN session, for example).
  • Both the nm-dnsmasq and xenDNSmasq script will also set up NAT if you have your guests on a hidden network to allow them access to the public network.