On Tue, Aug 28, 2012 at 11:45 AM, Tim Spriggs <t...@uahirise.org> wrote:
> On Tue, Aug 28, 2012 at 8:21 AM, Gurucharan Shetty <gshe...@nicira.com> wrote:
>> On Mon, Aug 27, 2012 at 4:43 PM, Tim Spriggs <t...@uahirise.org> wrote:
>>>
>>> On Thu, Aug 23, 2012 at 6:56 PM, Gurucharan Shetty <gshe...@nicira.com>
>>> wrote:
>>> >
>>> > Does this help for your use case?
>>> > http://openvswitch.org/pipermail/dev/2012-May/016972.html
>>> >
>>> > The scripts are all there. But, someone needs to call it.
>>> >
>>> > ifup --allow=ovs $list_of_bridges
>>>
>>> Interesting. I haven't applied this to my system but if I am
>>> understanding it correctly, this actually configures OVS on boot via
>>> /etc/network/interfaces. I'm still not convinced it would work since
>>> /etc/init.d/networking is called before openvswitch is running.
>>
>> It would work if you call the "--allow=ovs" command in
>> /etc/init.d/openvswitch-switch.
>> But it is probably a problem if you have some dependent directories mounted
>> through network and you want have all network interfaces through OVS.
>>
>>> I like
>>> the idea of configuring openvswitch in this manner however it would
>>> kill any ability to make permanent changes via the ovs-* commands
>>> which is a paradigm shift from what I have gathered from the
>>> documentation.
>>
>> This is true. During every boot/shutdown, interfaces are created and
>> destroyed.
>>
>>
>>>
>>> Maybe I am wrong but it seems like the expected
>>> workflow is something on the order of:
>>>
>>> 0) Install OVS
>>> 1) Configure OVS resources (using: ovs-vsctl ...)
>>> 2) Configure /etc/network/interfaces to generically reference OVS
>>> resources
>>> 3) Cross fingers and reboot
>>>
>>> The above would modify it to:
>>>
>>> 0) Install OVS
>>> 1) Configure /etc/network/interfaces to configure OVS
>>> 2) Cross fingers and reboot
>>>
>>> Thus eliminating any direct interaction with OVS.
>>
>> If I understand you correctly, you would like it if the permanent nature of
>> changes
>> done through ovs-vsctl manually after a boot should remain through boot
>> cycles.
>> And when new bridges are created, you go and look up /etc/network/interfaces
>> for any
>> post creation commands. I am not aware of any way you can do this right now.
>>
>
> That's exactly right. I guess I will architect my system differently then.
>
> Thanks for the help!
>
> -Tim

Just to follow up, I found a way to construct my interfaces file s.t.
the host gets its network configuration through the openvswitch bridge
without any changes to system scripts etc:


/etc/network/interfaces:
---
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual
        mtu 9000
        post-up ip link set $IFACE mtu 9000 up
        post-up sysctl -w net.ipv6.conf.all.autoconf=0
        post-up sysctl -w net.ipv6.conf.default.accept_ra=0

auto dom0vlan5
iface dom0vlan5 inet static
        pre-up ip link add $IFACE address 00:16:3e:cb:7b:b6 mtu 9000
up type veth peer name p$IFACE mtu 9000
        post-up ip link set p$IFACE up
        post-up sysctl -w net.ipv6.conf.$IFACE.autoconf=1
        post-up sysctl -w net.ipv6.conf.$IFACE.accept_ra=1
        address 192.168.5.224
        netmask 255.255.255.0
        gateway 192.168.5.1
        post-down ip link del $IFACE
---

Then add the above interface peer side into the wanted OVS bridge:

# ovs-vsctl add-br br0
# ovs-vsctl add-port br0 eth0
# ovs-vsctl add-br br5 br0 5
# ovs-vsctl add-port br5 pdom0vlan5
# ovs-vsctl show
bbbc44da-9531-4b7e-baee-e1778843db70
    Bridge "br0"
        Port "pdom0vlan5"
            tag: 5
            Interface "pdom0vlan5"
        Port "br0"
            Interface "br0"
                type: internal
        Port "br5"
            tag: 5
            Interface "br5"
                type: internal
        Port "eth0"
            Interface "eth0"
    ovs_version: "1.4.2"

Now there are no references from /etc/network/interfaces to OVS and
things "just work". There are still some boot-order problems in my
environment because services require $network to be up and
openvswitch-switch is not part of $network. However, networking
eventually makes it and the host is online after a reboot!

Hopefully this helps someone else.

Cheers,
-Tim
_______________________________________________
discuss mailing list
discuss@openvswitch.org
http://openvswitch.org/mailman/listinfo/discuss

Reply via email to