[ovs-dev] Bug#771863: Bug#771863: [PKG-Openstack-devel] Bug#771863: Bug#771863: Service does not start or parse interfaces correctly

[Fabio Fantoni]

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
>> dev at openvswitch.org
>> http://openvswitch.org/mailman/listinfo/dev