Il 23/12/2014 16:27, Gurucharan Shetty ha scritto:
I tried 2.3.0+git20140819-3 building it in wheezy with kernel 3.16 from
backports but bridge of my test was still not working:
auto xenbr0
allow-ovs xenbr0
iface xenbr0 inet static
address 192.168.1.90
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.200
ovs_type OVSBridge
ovs_ports eth0
auto eth0
You should not be using 'auto' above. eth0 is a port of an OVS bridge
and it should be configured after 'xenbr0' is configured.
allow-xenbr0 eth0
iface eth0 inet manual
ovs_bridge xenbr0
ovs_type OVSPort
auto xenbr1
allow-ovs xenbr1
iface xenbr1 inet static
address 192.168.45.91
netmask 255.255.255.0
network 192.168.45.0
broadcast 192.168.45.255
ovs_type OVSBridge
ovs_ports vlan100
allow-xenbr1 vlan100
iface vlan100 inet manual
ovs_bridge xenbr1
ovs_type OVSIntPort
ovs_options tag=100
ovs_extra set interface ${IFACE} external-ids:iface-id=$(hostname
-s)
Without applying the below mentioned patch, does your problem go away
if you remove all the 'auto' for xenbr0 and xenbr1 also?
Thanks for your reply.
I removed all auto and now works also without backports other patches.
Then ovs networks starts automatically on boot also without "auto", is
it correct?
For have it working I had to do "service networking restart".
I found probably final solution applying also this patch:
http://git.openvswitch.org/cgi-bin/gitweb.cgi?p=openvswitch;a=commitdiff;h=9a8b5cc1a3d941c0e33f3f5b5ac260a35a8130af
The above patch adds the ability to configure OVS with 'auto'
configured and additionally has the following information:
"""
Notes on dependencies:
---------------------
openvswitch-switch depends on $network, $named $remote_fs and $syslog to start.
This creates some startup dependency issues.
* Since openvswitch utilities are placed in /usr and /usr can be mounted
through NFS, openvswitch has to start after it. But if a user uses openvswitch
for all his networking needs and hence to mount NFS, there will be a deadlock.
So, if /usr is mounted through NFS and openvswitch is used for all networking,
the administrator should figure out a way to mount NFS before starting OVS.
One way to do this is in initramfs.
* Since openvswitch starts after $network, $remote_fs and $syslog, any startup
script that depends on openvswitch but starts before it, needs to be changed
to depend on openvswitch-switch too.
* Ideally, an admin should not add openvswitch bridges in the 'auto'
section of the 'interfaces' file. This is because, when ifupdown starts
working on bridges listed in 'auto', openvswitch has not yet started.
But, if the admin wants to go down this route and adds openvswitch bridges
in the 'auto' section, openvswitch-switch will forcefully be started when
ifupdown kicks in. In a case like this, the admin needs to make sure that /usr
has already been mounted and that a remote $syslog (if used) is ready to
receive openvswitch logs.
"""
Even if seems not good in some cases.
Does the above explanation give any hints on why it wouldn't work in some cases?
Yes
I don't know if also Jessie have this problem but probably yes. If yes I
think this bug is only partially solves with 2.3.0+git20140819-3.
I had also another start problem probably not related to this, after some
hours xenbr0 stopped to working.
I not found any useful errors about in logs, only some strange thing, in
ifconfig xenbr0 was without the static ip, in syslog keep tried to acquire
configuration with dhcp failing (dhcp server present and working in lan).
After "service networking restart" was working again but I not understand
was happen and why :(
Someone have any idea about?
Thanks for any reply and sorry for my bad english.
_______________________________________________
dev mailing list
d...@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
