[ovs-discuss] openvswitch existing port configuration after unclean reboot

Jesse Gross jesse at nicira.com
Mon Mar 12 15:57:32 UTC 2012


On Mon, Mar 12, 2012 at 8:34 AM, Frido Roose <fr.roose at gmail.com> wrote:
> Hello,
>
> I'm testing a cluster setup with KVM, and I encounter a problem when the
> host gets a reset (not a reboot), like when the host is fenced by the
> cluster.
> In this case, the ovs configuration is loaded from its database with the
> next reboot (like bridge ports that were configured for VMs that were
> running).
>
> When trying to start the first VM, it won't start because the port is
> already there:
>
> 14:29:16.973: 3470: error : qemuNetworkIfaceConnect:283 : Failed to add tap
> interface to bridge 'vbr314': Invalid argument
>
> That's because the vnet0 port is still there from before the host reset:
>
> # ovs-vsctl show
> 54473b1e-9509-4641-a885-e00ae1ff5382
>     Bridge "vbr316"
>         Port "vbr315"
>             tag: 315
>             Interface "vbr315"
>                 type: internal
>         Port "bond0"
>             Interface "eth0"
>             Interface "eth1"
>         Port "vbr316"
>             Interface "vbr316"
>                 type: internal
>         Port "vnet0"
>             tag: 314
>             Interface "vnet0"
>         Port "vbr314"
>             tag: 314
>             Interface "vbr314"
>                 type: internal
>     ovs_version: "1.4.0"
>
> The VM network configuration is like (it connects to the fake bridge vbr314)
> by using brcompat:
>     <interface type='bridge'>
>       <mac address='52:54:00:69:5c:9c'/>
>       <source bridge='vbr314'/>
>       <model type='virtio'/>
>       <address type='pci' domain='0x0000' bus='0x00' slot='0x03'
> function='0x0'/>
>     </interface>
>
> When doing a proper shutdown, VMs and networking is properly shut down, and
> the database is clean for the next startup of the host.
> What is the correct way to handle this situation?
>
> I could add an init script that cleans up the database (like deleting the DB
> or removing all existing vnet ports) at each boot, but that doesn't feel
> like the right way to go...

You should clean out any ephemeral state that you don't want after a
reboot.  This is effectively what most Linux-based hypervisors do.



More information about the discuss mailing list