Bridge support not detecting bridges correctly

Here's the output of brctl show on my host system.

bridge name bridge id STP enabled interfaces
admin 8000.001e689b5736 no eth0
storage 8000.001e689b5737 no eth1

However, in Cloudmin it doesn't show the storage bridge and shows xenbr0 & xenbr1, which don't exist. See attached screen shot.

Let me know if you need more info.

Closed (fixed)


Here's the brctl show output from another system that has three bridges.

bridge name bridge id STP enabled interfaces
admin 8000.00238b174530 no vlan10
customer 8000.00238b174530 no vif1.0
storage 8000.00238b174532 no vif1.1

On this one Cloudmin shows only xenbr0 & xenbr1.

Some more info that might be helpful...

I configure my bridges by hand (well, /etc/network/interfaces) as I have a complex setup of bonds, vlans & bridges and xen's network-bridge script didn't play nice with it so in my xend-config.sxp file the bridge-script is omitted altogether.

Ok, the problem here is that Cloudmin naively assumes that all Xen bridges are named xenbr* , and can be detected from the output of the ifconfig -a command.

I will fix this in the next release. However, till then the work-around is to edit /etc/webmin/servers/XXX.serv , where XXX is the unique ID of your Xen host system. In it, add the following line at the end :

xen_iface=admin customer storage

Also, do you plan to define an IP allocation range for each bridge?

I edited all of my .serv files for the Xen hosts, however I could not assign IP ranges to them because the For Interface dropdown only lists xenbr0/1 even though they're not selected. I entered my different IP ranges and I manually set the xen_ifaces line in the .serv files by hand.

I hadn't planned to enter the IP ranges into Cloudmin. My billing & customer management software contains IP management software and since I use that software as the authoritative customer information management system I have been specifying the address is Cloudmin manually during machine creation which is why there's just a bogus entry in the screenshot.

With the xen_iface and xen_ifaces lines set in the serv files I do not see where I get to select these bridges during machine creation. It still only provides a box for an IP Address. Where should I be able to select the other bridges?

Currently my work around for this is to just specify a vif = ['bridge=admin', 'bridge=storage'] line in the Other config file entries section of the advanced page, since the xen config files are parsed as python code the second vif line just supersedes the one added by Cloudmin.

Ok, I see now .. so would it be better for you if you could enter multiple IP addresses manually at system creation time, and have Cloudmin setup an interface on the Xen instance for each, corresponding to different bridges?

That is not possible currently, but could be added relatively easily.

Right, If I could enter IP addresses and select which bridge the vif's should join would be great.

I've implemented support for entering multiple IPs manually .. let me know if you'd like a pre-release build of Cloudmin that includes this.

I'd love a prerelease build to test with.

Let me know how to grab it.


Hey Jamie,

The new interface looks great, just going to deploy some tests now to test it out.

My initial feedback is that the dialog to specify bridges is static and does not accurately reflect the bridges on each host.

For instance my Create Xen dialog now shows what is in the attached screenshot. However, on one of my systems I'm using for testing & dev I do not have named bridges setup (nor a complex setup) so it uses just the default xenbr0 which does not show up in the screen shot. Other systems have just admin & storage but the customer bridge is still shown. To avoid mistakes by my staff it would be nice if the page reloaded the dialog based on the host system selected and only showed the bridges available on the selected system.

Hope this makes sense. I'll post more feedback after some tests.

Thanks, I'll see if I can fix that in the 3.2 Cloudmin release.

I'd recommend having the same bridges setup all all hosts if possible though, so that migration of Xen instances between them work properly..

Hey Jamie,

Found a bug in the bridge code. The environment is still the same as the screen shot in comment #8.

Admin Bridge = xen_ip_0 Customer Bridge = xen_ip_1 Storage Bridge = xen_ip_2

When I leave xen_ip_0 (admin) blank and fill in IP's for xen_ip_1 and xen_ip_2 (customer & storage) the following is generated in my config files:

vif = [ 'ip=,bridge=admin','ip=,bridge=customer' ]

Instead of:

vif = [ 'ip=,bridge=customer','ip=,bridge=storage' ]

More info, just created a new VM on a different host system and the following ended up in the config file.

vif = [ 'ip=,bridge=customer','ip=,bridge=admin' ]

Should've been

vif = [ 'ip=,bridge=customer','ip=,bridge=storage' ]

Ok, I don't think I considered that case .. I will take a look at this and get it fixed in the next release.

It will be possible to select which bridges get IPs in the next release, as requested.

Automatically closed -- issue fixed for 2 weeks with no activity.

Hey Jamie,

Yesterday you said Cloudmin 3.2 was out and contained the new bridge code, however my copy still says there's no new modules available when I try to update.

Updating Webmin modules ..

No Webmin updates for this version.

Is this because of the pre-release version you gave me? What's the best way to upgrade from this point?

You should be able to update from the command line with :

apt-get install webmin-server-manager

if that doesn't work, what is the output from :

dpkg --list webmin-server-manager

Hi Jamie,

I just tried to create a guest after upgrading to 3.2 and the problem still exists. I entered an address into the fields for the Customer & Storage bridges and Cloudmin ended up assigning Admin & Storage in the cfg file.

I know from comment #9 that you recommend having the same bridges for each host system, but practically this is unfeasible. We manage virtual systems in 3 different environments, each with their own network characteristics (for instance, in the office we have lan/dmz/voip, in production we have admin/customer/storage, etc).

I think the solution to this is to have the create page refresh when you change the select box for the system the new image is to be hosted on and have the type_xen_create_form function output the bridges that exist on the selected system.


Yeah, that sounds like the only real solution .. I'll look into this for the next release.

Ok, I'm making progress on this now .. let me know if you'd like a pre-release version to test with.

Would love one.

Let me know where to grab it and I'll provide you some feedback tomorrow. I have a bunch of VM's to create tonight.

Ok, I will email you a new version with this fix ..

I installed the new version. Interface selection with different bridge setups looks great!

But something strange just happened...

I went into the create xen dialog and played around with the interface selection, then when into Module Config > Xen Settings and changed the default additional config entries.

Back to the create xen dialog. First thing I noticed is that my default host wasn't selected. So into Host Systems > Xen Host Systems I went and sure enough the host I wanted to be default was still select. I click make default anyways and the save took longer than usual to complete. Now I went back the creation dialog and my default still wasn't select BUT now I'm missing some systems from the drop down altogether.

Xen Host Systems shows 6 systems - Create Xen Instance shows 4.


Even stranger, I just looked through the code in the frame and the host_change function still has 6 entries even though the drop down only has 4.

Getting worse, down to 2 systems in the drop down now.

Each of the systems that disappeared from the list have changed their status to this:

Last status Webmin down (Checked at 05/Nov/2009 02:10)
Detailed status error Failed to get status from Webmin in 30 seconds

While writing this post they started to come back. My backups are running right now so I think that might have something to do with it as the status checks take a long time.

I'll check it in the morning and see how it is.

Yes, if the hosts are loaded to the point where they cannot respond to Webmin RPC requests, they might fail their status checks and thus disappear from the host list temporarily..

All my hosts are back up and available in the list. Sorry about the false alarm.

Just created a machine using 3.4 and it worked flawlessly!

Thanks for the great work on this.

Automatically closed -- issue fixed for 2 weeks with no activity.