Bug 969027

Summary: Error starting domain: Cannot get interface MTU on 'ovsbr0': No such device
Product: [Fedora] Fedora Reporter: Anil Vettathu <avettath>
Component: libvirtAssignee: Laine Stump <laine>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 19CC: avettath, berrange, clalancette, dallan, itamar, jforbes, jyang, laine, libvirt-maint, me, veillard, virt-maint
Target Milestone: ---Flags: avettath: fedora_requires_release_note?
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-05-30 17:49:18 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
vm's dumpxml none

Description Anil Vettathu 2013-05-30 13:59:02 UTC
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
libvirt-1.0.5.1-1.fc19.x86_

How reproducible:
Always


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

2. 

# 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
    self._backend.create()
  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 14:45:09 UTC
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 17:49:18 UTC
# ovs-vsctl show
e0cbfad8-5d4b-435e-a7c9-4ec8cf9cfd40
    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"

=======

But,

#  systemctl status openvsiwtch.service
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 04:12:00 UTC
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!