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

[Frido Roose]

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...

Thanks for bringing some light in the darkness...
Frido
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20120312/20c81ba6/attachment.html>