[1] http://wiki.hetzner.de/index.php/Xen_mit_Routing_und_Bridge
[2] http://www.henningweiler.de/?p=85

1. Preparation

First, you copy ‘vif-route’ to ‘vif-virtual’ and ‘network-route’ to ‘network-virtual. Both are located in /etc/xen/scripts. The, you’ll have to patch the file ‘vif-virtual’ :


--- vif-route 2008-04-25 15:03:45.000000000 +0200
+++ vif-virtual 2008-05-02 14:29:22.725192247 +0200
@@ -47,6 +47,11 @@
done
fi

log debug "Successful vif-route $command for $vif."


The host (dom0) has to have a bridge on startup, which you can create in /etc/network/interfaces and give it an internal IP. Mine looks something like this:


auto xenintbr
iface xenintbr inet static
address 10.10.10.100
netmask 255.0.0.0
pre-up /usr/sbin/brctl addbr xenintbr
post-up /usr/sbin/tunctl -t tap0
post-up /usr/sbin/brctl addif xenintbr tap0
post-down /sbin/ifconfig xenintbr down
post-down /usr/sbin/brctl delbr xenintbr
post-down /usr/sbin/tunctl -d tap0
# bridge_maxwait 0
# bridge_fd 0
# bridge_hello 0
# bridge_stp off
post-up /sbin/ifconfig xenintbr 10.10.10.100 netmask 255.0.0.0


Now edit the file /etc/xen/xend-config.sxp and substitute the vif-route and network-route entries with the following entries:


(network-script network-virtual)
(vif-script vif-virtual)


2. DomU Configuration

The configuration for the virtual Network Interfaces for the corresponding DomU configuration file has to be setup in the following way:


vif = [ 'ip=xx.xx.xx.xx,mac=aa:bb:cc:dd:ee:ff,vifname=domUname-vif',
'mac=aa:bb:cc:dd:ee:ff,vifname=domUname-vif-br']


The first line describes the public IP(v4) address in your providers subnet. The second line describes the internal interface. Remember to change the MAC Adresses for both interfaces since those have to be different!

The extension ‘-vif’ or ‘-vif-br’ determines if the interface is connected to the external interface or to the internal bridge, whereby the ‘-vif-br’ resembles the bridge. With the configuration shown above, the domU will have two interfaces (eth0 and eth1) where eth0 points to the external interface and eth1 to the internal bridge.

3. Finishing Touches

To be able to use the network, the domU internal network configuration in /etc/network/interfaces has to be changed to hold an internal IP address on eth1 (which corresponds to an IP address in the subnet you specified in the bridge configuration).

in order to setup a new server, I had to deal with this more or less troublesome topic. I want to give everybody a hint who is facing trouble with this.

The Setup:
- Debian Lenny (Kernel 2.6.26-2-xen-amd64) 64 Bit host and 64 Bit guests
- xen-hypervisor 3.2-1

The Goal:
I. have a directly routed interface for the public IPs
II. create a virtual LAN between the domUs
III. let the hosts on the virtual LAN talk to the outside world (those are mostly the domUs, which do not have a public IP)

First, for I. and II. go ahead and apply the tutorial in [1]

In addition to that, I had to perform the following operations:
edit /etc/xen/scripts/vif-common.sh and add the two lines indicated

vifname=$(xenstore_read_default "$XENBUS_PATH/vifname" "")
if [ "$vifname" ]
then
if [ "$command" == "online" ] && ! ip link show "$vifname" >&/dev/null
then
do_or_die ip link set "$vif" down ### ADD THIS LINE
do_or_die ip link set "$vif" name "$vifname"
do_or_die ip link set "$vifname" up ### ADD THIS LINE
fi
vif="$vifname"
fi

Ok, now there is something you should keep in mind:
While editing your domU config be sure to keep the vifname parameter SHORT!! I called it ‘mysql-mirror-vif-br’ which was way too long, which then resulted in a non-starting script. The script did not tell me anything. Not on stdout not in the logs. Now it’s ‘mymirr-vif-br’ which is fine.

For III. do the following for every IP you want to have internet access from the inside of the respective domU:

iptables -t nat -A POSTROUTING -o eth0 -s virtualLanIP/32 -j MASQUERADE

Hope this helps someone.

Cheers!

[1] Hetzner Dokuwiki: http://wiki.hetzner.de/index.php/Xen_mit_Routing_und_Bridge

This shall be a little how-to for all those people who discover the same trouble!

The setup I had to deal with:
- Ubuntu (x64 Server)
- CUPS 1.2.8
- 2x Kyocera Mita FS-1030D attached via USB

The problem:
If you connect both printers, they both get the same ID:

# lsusb
Bus 004 Device 093: ID 0482:0015 Kyocera Corp.
Bus 004 Device 092: ID 0482:0015 Kyocera Corp.


AND (even worse) are both mapped to usb://Kyocera/FS-1030D

An auto-installation on the cups web interface will result in a success, BUT you’ll only be able to print on the first of the two USB devices. So not a good solution.

OK, this is where you want to go:

1. Set up the printer(s) using the web interface.
2. Fire up your console and goto /dev/
3. Find the files usblp0 and usblp1 (depending on your system, there might be a sub folder named ‘usb’. If so, see if there are two files named ‘lp0′ and ‘lp1′ in existance) and pad yourself on the back ;)
4. Edit /etc/cups/printers.conf with your favourite editor.
5. You’ll find the first printer which looks like this:

<Printer Kyocera_FS-1030D_USB_1>
Info Kyocera FS-1030D
Location Local Printer
DeviceURI usb://Kyocera/FS-1030D
State Idle
StateTime 1231879830
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy retry-job


Leave it like this!! (Otherwise, CUPS web interface will harass you with newly found printers.)

6. Right under the first printer you’ll find the second printer (and the third, the fourth, [...]) named <Printer Kyocera_FS-1030D_USB_2> for example. THERE (and on possibly other following identical printers) change the following line

DeviceURI usb://Kyocera/FS-1030D

to

DeviceURI file:/dev/usblp1

The other printers below need their equivalent usb device link. You could to a

# echo usblp1 > /dev/usblp1

which will actually print the word ‘usblp1′ on the printer. If you do so with all of your printers, you’ll know the device link ;)

Ok, we are not quite there, yet. I found a strange behaviour of CUPS, when you switch the printers off over night and turn them on again the next morning. Somehow, having this configuration, CUPS simply quits without following any shutdown procedures. No log entries, no good bye letter, nothing.

In order to detect and overcome this situation, this little script monitors the cups daemon and restarts it if necessary:


#!/bin/bash
#
# cupsMon.sh -- A Monitor for CUPS
#
# @author Henning Weiler
# @version 1.0
#

if ps --pid $CUPSPID | grep "cupsd" >/dev/null; then
exit 0
else
rm -f /var/run/cups/cupsd.pid /var/run/cups/cups.sock
/etc/init.d/cupsys start
fi
else
/etc/init.d/cupsys start
fi

I put it in my root home directory and gave it a little ‘chmod +x’.

In your /etc/crontab add the following line:

9 * * * * root /root/cupsMon.sh >> /dev/null

This will run the monitor every 9 minutes. I did not want to run it every minute, since switching on multiple printers may take a while.

If you have any questions or concerns, please comment.