Re: [Xen-users] Networking with more NIC's

[jez <jez@xxxxxxxxxx>]

On Sat, Mar 17, 2007 at 11:22:24PM +0100, Peter Fastré wrote:
> 
> root@vm01:~# brctl show
> bridge name     bridge id               STP enabled     interfaces
> xenbr0          8000.feffffffffff       no              vif0.1
>                                                        peth0
> 
> Seems to be a little better? But the default route is still gone after
> starting xen.
> 

I'm pleased with this part. But the rest is bugging me now.

> 
> Reboot your server to give it a fresh start. Then check 'ifconfig' and
> >also 'brctl show' to see that there is only the one bridge, xenbr0. If
> >all looks well, then try to start a DomU.
> 
> 
> Still no success.
> I'm doing some research on my own (mailling list/internet/configuration
> examples), and tried a lot of different values in the .sxp files, in the
> configuration files.
> I tried changing the vif section:
> 
> # By default, no network interfaces are configured.  You may have one
> created
> # with sensible defaults using an empty vif clause:
> #
> # vif = [ '' ]
> #
> # or optionally override backend, bridge, ip, mac, script, type, or vifname:
> #
> # vif = [ 'mac=00:16:3e:00:00:11, bridge=xenbr0' ]
> #
> # or more than one interface may be configured:
> #
> # vif = [ '', 'bridge=xenbr1' ]
> 
> When I read this, one would think that it's possible to boot a vm without
> network interface? I know this wouldn't make sense, but it could be useful
> for testing, not? But when I remove the vif option, the vm also doesn't
> boot.
> 

I just checked back over previous posts, and I can't find whether or not
I asked you to make certain that:

    (vif-script vif-bridge)

is set in your xend-config.sxp. This is the default setting, but I think
you should check just in case.

If you wanted to try to test with *no* DomU interfaces, you should set
vif as follows:

    vif = []

This is actually a python script and you want to define an empty list -
not no list. 

If you wanted to tell vif-bridge explicity to use the bridge we created
you would do:

    vif = [ 'bridge=xenbr0' ]

However, if there is only one bridge in existence on your machine, the
vif-bridge script will automatically use that. 

Please note that the vif-bridge script does *not* create bridges - it
just adds and removes interfaces from bridges that already exist. The
fact that you can't start a DomU suggests that there is a bug in
vif-script as far as Slackware is concerned.

And the following is also a worry. It suggests to me that there is a bug
in bridge-script as far as Slackware is concerned. It looks to me that
your very act of trying to check the status of the bridge with
"./network-bridge status" is what is responsible for corrupting the
bridge. Any chance you can check the status of the bridge with 
"brctl show" immediately before you do this other check?
>
> Another thing I try.
> I set the line in the config.sxp back to (network-script network-bridge)
> 
> When I do this, I find something strange too:
> root@vm01:/etc/xen/scripts# ./network-bridge status
> ============================================================
> 5: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
>    link/ether 00:30:48:33:3b:75 brd ff:ff:ff:ff:ff:ff
>    inet 10.201.1.100/24 scope global eth1
> 12: xenbr1: <BROADCAST,NOARP,UP> mtu 1500 qdisc noqueue
>    link/ether fe:ff:ff:ff:ff:ff brd ff:ff:ff:ff:ff:ff
> 
> bridge name     bridge id               STP enabled     interfaces
> xenbr1          8000.feffffffffff       no              vif0.1
>                                                        peth1
> 
> 10.200.1.0/24 dev eth0  proto kernel  scope link  src 10.200.1.100
> 10.201.1.0/24 dev eth1  proto kernel  scope link  src 10.201.1.100
> 127.0.0.0/8 dev lo  scope link
> default via 10.200.1.1 dev eth0  metric 1
> 
> Kernel IP routing table
> Destination     Gateway         Genmask         Flags Metric Ref    Use
> Iface
> 10.200.1.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
> 10.201.1.0      0.0.0.0         255.255.255.0   U     0      0        0 eth1
> 127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo
> 0.0.0.0         10.200.1.1      0.0.0.0         UG    1      0        0 eth0
> ============================================================
>
> 
> It seems it's creating a xenbr1 because it thinks that's my outgoing
> interface. So I guess your suggestion should be followed, and I have to add
> something to the xend-config.sxp file to get things right.
> 

This stuff is just wierd.

> If this has to do with my distribution (Slackware), please just say that. I
> don't like to switch, but if necessary, I'll do that. I tried ubuntu
> 6.0664-bit, which worked fine, but not all my machines are 64-bit.
> With ubuntu
> 6.06 32-bit I ran into big problems because of the TLS-libs, which should be
> recompiled with some options (something about no segments). I didn't succeed
> doing that. I did succeed recompiling the glibc on my slackware box, so now
> I'm using this.
> But if all my problems would be resolved by choosing some other
> distribution, please let me know. I'm working on this Xen-setup for more
> than two weeks now, and I just don't know it anymore. I considered moving to
> the commercial version of xen, but my server is not supported by them (3ware
> 9650 controller). I'm also willing to pay someone to get installation
> support, I just want it to work :(
> 

Okay, I don't want to start a troll here, but... Ubuntu is great on the
desktop - really great. However, if you take Ubuntu off the desktop you
are using Debian - and if you're going to use Debian then do it
directly. If I was recommending a distro to you for a production
environment, I'd recommend you go with Debian Etch.

This said, I think there is a lot to be said for sticking with what you
know. Debian has a large learning curve and it's not one you want to
climb in a production enviroment IMO. But whatever you decide to do from
here, I certainly think that you should increase you options by
learning a second system and learning it well.

In answer to your question: Yes, I definitely think that you can get xen
working with little or no fuss by switching to another distribution. 
However, I don't think that the problems you are having are really 
that serious. It's just likely that the shell scripts under
/etc/xen/scripts need a bit of tweaking to get things working. In fact,
it would be a simple matter to just by-pass the xen scripts altogether
and just use your own. This is what I have done on one of my boxes.
There are no really serious problems here, just misunderstandings.

Anyway, I'll ping you off-line about taking a closer look at your setup.

jez

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users