[ovs-dev] [ovs-discuss] Problem with KVM Creating Bridge

Thu Apr 5 17:12:08 UTC 2012

On Wed, Apr 4, 2012 at 10:45 PM, Jon <three18ti at gmail.com> wrote:

> Hello,
>
> Thanks for the reply.
>

> Here are the logs from that day,
> Apr 03 08:56:31|00001|vlog|INFO|opened log file
> /var/log/openvswitch/ovs-brcompatd.log
> Apr 03 11:51:10|00002|brcompatd|WARN|ovs-vsctl exited (exit status 1)
> Apr 03 11:51:10|00003|brcompatd|WARN|ovs-vsctl wrote to stderr:
> ovs-vsctl: cannot create a port named vnet0 because a port named vnet0
> already exists on bridge br0
> Apr 03 11:53:15|00004|brcompatd|WARN|ovs-vsctl exited (exit status 1)
> Apr 03 11:53:15|00005|brcompatd|WARN|ovs-vsctl wrote to stderr:
> ovs-vsctl: cannot create a port named vnet0 because a port named vnet0
> already exists on bridge br0
>
This line above tells that vnet0 interface already existed on br0 when
libvirt tried to start the VM again after the reboot.

Starting from libvirt 0.9.11 we added direct Open vSwitch support. So if it
is an
option for you to use libvirt 0.9.11 then you wouldn't encounter this
problem
anymore - it deals with abrupt restarts more nicely. Just edit the Domain
XML file (
http://www.redhat.com/archives/libvir-list/2012-February/msg00553.html)
and don't use the brcompatd anymore.

Apr 03 11:57:36|00002|daemon|INFO|pid 2199 died, killed (Terminated),
> exiting
> Apr 03 11:57:37|00001|vlog|INFO|opened log file
> /var/log/openvswitch/ovs-brcompatd.log
> Apr 03 11:58:05|00002|brcompatd|WARN|ovs-vsctl exited (exit status 1)
> Apr 03 11:58:05|00003|brcompatd|WARN|ovs-vsctl wrote to stderr:
> ovs-vsctl: cannot create a port named vnet0 because a port named vnet0
> already exists on bridge br0
> Apr 03 12:15:29|00004|brcompatd|INFO|network device eth1 destroyed,
> removing from bridge br0
>
> It definitely looks like there is a problem destroying the bridge.
>
s/bridge/interface

>
> After a controlled reboot I was receiving the same error, but I believe
> that was because of the kernel upgrade and my initial failure to rebuild
> the ovs kernel module.  However, after rebuilding the kernel module I'm
> receiving a different error:
>
> root at kitt:~# virsh start solo.rebase.ubuntu-server-11.10-oneiric-x86_64
> error: Failed to start domain
> solo.rebase.ubuntu-server-11.10-oneiric-x86_64
> error: internal error Process exited while reading console log output:
> chardev: opening backend "pty" failed: Exec format error
>
This seems to be libvirt issue. I could be wrong, but the chardev most
likely
here is what kvm creates to communicate with libvirt. I would recommend
to ask this in libvirt mailinglist.

>
> I'm pretty sure this is a libvirt issue but I've just started researching
> the issue...  Once I've figured out that issue, I'll try a controlled
> reboot without the kernel upgrade.
>
> Best Regards,
> Jon A
>
> On Wed, Apr 4, 2012 at 11:32 AM, Ben Pfaff <blp at nicira.com> wrote:
>
>> On Tue, Apr 03, 2012 at 12:23:36PM -0600, Jon wrote:
>> > Yesterday, when I ran the ovs-vsctl commands, I was able to successfully
>> > start my VMs, I had a power outage, and the machine was rebooted, today
>> I
>> > am unable to "add the bridge" again, because it already exists, but I am
>> > unable to use the bridge.
>>
>> That is strange.  What's in the OVS log from the time that
>> ovs-vswitchd started up?
>>
>> OVS by default persists the bridge setup from one boot to another.  If
>> you want to instead delete all the bridges at boot then you can
>> configure it to do that, by ensuring that --delete-bridges gets passed
>> to ovs-ctl from your startup scripts.
>>
>
> On Wed, Apr 4, 2012 at 12:20 PM, Ansis Atteka <aatteka at nicira.com> wrote:
>
>>
>>
>> On Tue, Apr 3, 2012 at 11:23 AM, Jon <three18ti at gmail.com> wrote:
>>
>>> Hello All,
>>>
>>> I am attempting to use OpenV Switch as a replacement for the standard
>>> bridge controls for KVM.
>>>
>>> After a reboot, I am receiving the following error when attempting to
>>> start my KVM VMs:
>>>
>>> root at kitt:~# virsh start solo.rebase.ubuntu-server-11.10-oneiric-x86_64
>>> error: Failed to start domain
>>> solo.rebase.ubuntu-server-11.10-oneiric-x86_64
>>> error: Unable to add bridge br0 port vnet0: Invalid argument
>>>
>>> I had this problem yesterday, and resolved it by creating the bridge by
>>> running the following commands,
>>>
>>> ovs-vsctl add-br br0
>>> ovs-vsctl add-port br0 eth1
>>>
>>> When running these commands today, I receive the following errors:
>>>
>>> root at kitt:~# ovs-vsctl add-br br0
>>> ovs-vsctl: cannot create a bridge named br0 because a bridge named br0
>>> already exists
>>> root at kitt:~# ovs-vsctl add-port br0 eth1
>>> ovs-vsctl: cannot create a port named eth1 because a port named eth1
>>> already exists on bridge br0
>>>
>>> Yesterday, when I ran the ovs-vsctl commands, I was able to successfully
>>> start my VMs, I had a power outage, and the machine was rebooted, today I
>>> am unable to "add the bridge" again, because it already exists, but I am
>>> unable to use the bridge.
>>>
>>> I am running Ubuntu 12.04 Server, but am pretty sure this isn't the
>>> problem as it was working.
>>>
>>> I followed the instructions found here for installing and configuring
>>> OpenV Switch:
>>> http://blog.allanglesit.com/2012/03/linux-kvm-ubuntu-12-04-with-openvswitch/
>>> Initially, I only was using one NIC, so when I attempted to add the
>>> bridge, I killed my network connection; of course this is a remote
>>> machine... :)
>>>
>>> Anyway, after rebooting, I still had no network, so I destroyed the
>>> bridge and recreated it using my 2nd NIC Eth1 (Eth2 is management, Eth1 is
>>> my bridge interface; my 2nd NIC is Eth1... it's just the way they are
>>> placed on the chassis), then I was able to successfully start my VM with
>>> the command:
>>>
>>> root at kitt:~# virsh start solo.rebase.ubuntu-server-11.10-oneiric-x86_64
>>>
>>> Today, after my reboot, it returns an error:
>>> error: Failed to start domain
>>> solo.rebase.ubuntu-server-11.10-oneiric-x86_64
>>> error: Unable to add bridge br0 port vnet0: Invalid argument
>>>
>>> On a hunch, I recreated my steps from yesterday:
>>>
>>> root at kitt:~# ovs-vsctl del-br br0
>>> root at kitt:~#  ovs-vsctl add-br br0
>>> root at kitt:~# ovs-vsctl add-port br0 eth1
>>> root at kitt:~# virsh start solo.rebase.ubuntu-server-11.10-oneiric-x86_64
>>> Domain solo.rebase.ubuntu-server-11.10-oneiric-x86_64 started
>>>
>>> And success...  This is great for now, as my VMs are up and running (and
>>> fortunately this is not a production environment, so I don't have customers
>>> yelling at me), but what happens next time I want to reboot my VM Host
>>> (admittedly it doesn't happen often, but as Ubuntu is still in beta,
>>> updates are more frequent), I really don't want to have to go through this
>>> song and dance every time I reboot...
>>>
>>> Initially, I thought it might have something to do with the qemu-ifup
>>> script, because it uses brctl,
>>>
>>> I could be wrong, but I believe the problem is that Open vSwitch keeps
>> its state
>> after abrupt reboots, while libvirt discards it. Hence the vnet0
>> interface remains
>> hanging to the bridge from the old session and libvirt can't add it with
>> duplicate
>> name after the reboot.
>>
>> To verify this: Next time you can't start the VM, could you make sure that
>> vnet0 interface is already attached to the bridge even when VM is not
>> running?
>>
>>
>> #!/bin/sh
>>>
>>> nic=$1
>>>
>>> if [ -f /etc/default/qemu-kvm ]; then
>>>     . /etc/default/qemu-kvm
>>> fi
>>>
>>> if [ -z "$TAPBR" ]; then
>>>     switch=$(ip route list | awk '/^default / { print $5 }')
>>>     if [ ! -d "/sys/class/net/${switch}/bridge" ]; then
>>>         switch=virbr0
>>>     fi
>>> else
>>>     switch=$TAPBR
>>> fi
>>>
>>> ifconfig $nic 0.0.0.0 up
>>> brctl addif ${switch} $nic
>>>
>>> But after deleting and recreating the bridge, I am not so sure...  I
>>> would think that if the /etc/qemu-ifup script was executed, then it
>>> wouldn't matter if I made changes to openvswitch.  Admittedly, I don't know
>>> enough about libvert and the way it manages networks to be certain if it is
>>> even a openvswitch problem, can anyone shed some light on the problem?
>>>
>>> Thanks for your time,
>>> Jon
>>>
>>> _______________________________________________
>>> discuss mailing list
>>> discuss at openvswitch.org
>>> http://openvswitch.org/mailman/listinfo/discuss
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20120405/e8e31881/attachment-0003.html>