Bug 969027 - Error starting domain: Cannot get interface MTU on 'ovsbr0': No such device
Error starting domain: Cannot get interface MTU on 'ovsbr0': No such device
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Laine Stump
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2013-05-30 09:59 EDT by Anil Vettathu
Modified: 2013-06-07 00:12 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-05-30 13:49:18 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
avettath: fedora_requires_release_note?

Attachments (Terms of Use)
vm's dumpxml (3.62 KB, text/xml)
2013-05-30 09:59 EDT, Anil Vettathu
no flags Details

  None (edit)
Description Anil Vettathu 2013-05-30 09:59:02 EDT
Created attachment 754869 [details]
vm's dumpxml

Description of problem:

Upgrade fedora from 18 to 19.
After upgrade none of the VMs attached ovs brige are starting

Version-Release number of selected component (if applicable):
# cat /etc/redhat-release 
Fedora release 19 (Schrödinger’s Cat)
# rpm -q libvirt

How reproducible:

Steps to Reproduce:
# cat ovs.xml 
<interface type='bridge'>
      <source bridge='ovsbr0'/>
      <virtualport type='openvswitch' />
      <model type='virtio'/>


# virsh attach-device rhevh6 --config ovs.xml
Device attached successfully

3. start the vm using virt-manager or virsh

Actual results:

Error starting domain: Cannot get interface MTU on 'ovsbr0': No such device

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 101, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 123, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1174, in startup
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 692, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: Cannot get interface MTU on 'ovsbr0': No such device

Expected results:

vm will start with virtual interface attached to ovsbridge. It was working fine on f18.

Additional info:
Comment 1 Laine Stump 2013-05-30 10:45:09 EDT
The error message says that the "ovsbr0" device doesn't exist. Libvirt doesn't/can't create openvswitch bridges, it only uses bridges that already exist. What is the output of:

   ovs-vsctl list-br

?? If it's empty, then you need to create the bridge with

   ovs-vsctl add-br ovsbr0

If you get error messages, you haven't started the openvswitch service; run

   systemctl start openvsiwtch.service

then do list-br to make sure your bridge is there (and create it if not).
Comment 2 Anil Vettathu 2013-05-30 13:49:18 EDT
# ovs-vsctl show
    Bridge "br0"
        Port "vlan20"
            tag: 20
            Interface "vlan20"
                type: internal
        Port "br0"
            Interface "br0"
                type: internal
        Port "vlan10"
            tag: 10
            Interface "vlan10"
                type: internal
    Bridge "ovsbr0"
        Port "ovsbr0"
            Interface "ovsbr0"
                type: internal
        Port "vnet28"
            Interface "vnet28"
        Port "vnet27"
            Interface "vnet27"
        Port "em1"
            Interface "em1"
        Port "vnet6"
            Interface "vnet6"
        Port "vnet5"
            Interface "vnet5"
        Port "vnet7"
            Interface "vnet7"
        Port "vnet4"
            Interface "vnet4"
    ovs_version: "1.10.0"



#  systemctl status openvsiwtch.service
   Loaded: error (Reason: No such file or directory)
   Active: inactive (dead)


So I stopped the service .. and restarted it again. Now its working as expected.

Closing the bug.
Comment 3 Pete Travis 2013-06-07 00:12:00 EDT
I'm removing the fedora_requires_release_note tag here; please advise if you think I shouldn't have. Thanks for the added signal, anyway!

Note You need to log in before you can comment on or make changes to this bug.