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
|
Home