This may seem a truly useless idea to a lot of people, however I’ve always found having a ‘lab’ at home capable of building pretty much every system scenario very useful. Dealing daily with VMware ESX servers and VMs in a production environment means that I can never “fiddle” around and get to grips with whats under the hood or deal with the unsupported or hidden functionality. My Xen server has allowed me to create pretty much every scenario I may need Oracle RAC clusters, interoperability between various operating systems and various development environments. When I first received the server that I use for my environments my first choice of setup was going to be a VMware ESX setup, however the hardware requirements restrict most installations to a subset of hardware configurations meaning I couldn’t install it. Originally it would have been impossible to install it under a xen HVM on the basis that the virtualised network adapters are unsupported by ESX, however luckily from 3.4.0 onwards the xen-tools have been updated and allow the use of the e1000/e100 network.Read More
The most common method for networking using xen is to use a network bridge with your physical ethernet and then the virtual nics associated with xen domains. The default install and configuration will result in a default xen bridge (xenbr0) which will have your ethernet and virtual nics in. This information has to be explicitly declared in the various xen configuration files, however xen will take care of the actual plumbing and configuring of the bridge and the interfaces.
However, xen has an oddity (in my opinion) it appears that xend will monitor the bridges on your dom0 and add any other bridges to it’s state. Which means should you manually create a bridge e.g.
spike ~ # brctl addbr testbr0
xend will see that this bridge has been created and add it to it’s state configuration. On a reboot or restart of xend, what will happen is that xend will configure the networking back to the state that it recorded. This means that not only will xenbr0 be created so will testbr0, which wouldn’t be a problem if your virtual nics were added to the correct bridge (xenbr0). However they more than likely be added to testbr0 meaning that your domU’s will have no networking, unless you manually move the virtual nic to the correct bridge.
To permanently remove bridges you need to stop xend (/etc/init.d/xend stop *BEWARE* this will stop all domUs) then go to /var/lib/xend/state/ and edit the network.xml. The entire network uuid section containing the bridge you want removing will need deleting, ensure you back everything up before hand.
Starting xend now will result in only the correct bridges being created and the domUs nics will be added to the correct bridge.Read More