Hi Tim,
this solution works. I have setup the network as above and in the VM
with an IP from the subnet 10.1.19.0.
I am little bit confused. Why does we need an IP on the bridge on XEN
side? I thought a bridge works on layer 2.
Anyway thanks for your help
Regards
Christian
Tim Post wrote:
> On Fri, 2007-03-16 at 03:21 +0800, Tim Post wrote:
>
> Sorry, forgot to show you the alternate config :
>
>> On Thu, 2007-03-15 at 20:06 +0100, Christian Placzek wrote:
>>
>>> auto eth1
> becomes auto xen-br1
>>> allow-hotplug eth1
> you can add allow-hotplug xen-br1 but should not be needed
>>> iface eth1 inet static
> iface xen-br1 inet static
>>> address 10.1.1.201
>>> netmask 255.255.255.0
>>> network 1.1.1.0
> #then add:
> bridge_fd 0
> bridge_maxwait 0
> bridge_helo 0
> bridge_stp off
> bridge_ports eth1
>
> Just tell the bridge what eth device to port, or 'none' if you want to
> setup a dummy bridge to serve as a switch for some guests. You need to
> give it an IP even if its a dummy (.1 in any reserved address is fine),
> just no gatway.
>
> Contradictory, every bridge that lets guests talk to the internet will
> need a gateway, or it will only let guests talk to the same network as
> the bridge. Tempting as it may seem, leave stp off, you don't wanna go
> there.
>
> Remember that when you re-start networking, you'll need to re-attach the
> vif's to their respective bridges. you can see scripts/vif-* for how to
> manage this within your own scripts.
>
> Another way to do it is with a vif-detach / attach, but I haven't played
> with that way yet.
>
> Best, and sorry for the double post. I forgot to paste my version
> instead of the quoted one.
>
> --Tim
>
>> Stop using network-bridge , its there to construct and deconstruct a
>> bridge so that Xen itself is non destructive (no changing of network
>> init needed to install it).
>>
>> Since you are doing the more production-sensible thing by letting Debian
>> handle your bridges in init, there's no need to be using network-bridge.
>> Better, more structured and sensible control over all of that is partly
>> achieved by how you construct your guests.
>>
>> First thing to do, get rid of network-bridge
>>
>> In /etc/xen/scripts/ do
>>
>> echo -e "#!/bin/sh\nexit 0" > network-dummy && chmod +x network-dummy
>>
>> Then in /etc/xen/ change xend-config.sxp to call network-dummy instead
>> of network-bridge.
>>
>> Secondly (just suggesting) :
>>
>> Specify vifname= in the vif [] containers in the guests to keep it all
>> nice and neat. If you name the vif after the domname (or something else
>> specific and meaningful), bandwidth accounting becomes *very* easy over
>> an entire farm, which sounds like it would also lend well to your setup.
>>
>> Best,
>> --Tim
>>
>>
>> _______________________________________________
>> Xen-users mailing list
>> Xen-users@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-users
>
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-users
>
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|