On Mon, Mar 12, 2012 at 8:34 AM, Frido Roose <[email protected]> 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. _______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
