Bug #1053: Open vSwitch - vlan not working, wrong interface? (XEN) - OpenNebula - OpenNebula Development pages

Bug #1053

Open vSwitch - vlan not working, wrong interface? (XEN)

Added by Oskar Johansson over 9 years ago. Updated over 8 years ago.

Status:

Closed

Start date:

01/07/2012

Priority:

Low

Due date:

Assignee:

Jaime Melis

% Done:

Category:

Drivers - Auth

Estimated time:

0.50 hour

Target version:

Resolution:

worksforme

Pull request:

Affected Versions:

OpenNebula 3.2

Description

I've found a bug that causes vlan to not work - packets are simply dropped. As far as I can tell, setting the vlan-tag on the tapX.Y-interface instead of the vifX.Y-interface solves the problem.

I've found a solution, but I would consider it a hack. I made a simple addition to OpenvSwitch.rb and replaced the following:

            OpenNebula.exec_and_log(cmd)

with this:

            OpenNebula.exec_and_log(cmd)
            #For some reason we have to do this..
            cmd = cmd.gsub("vif", "tap")
            OpenNebula.exec_and_log(cmd)

With this patch applied vlan starts to function, without all packets are dropped.

Tested with 3.1.90

History

#1 Updated by Ruben S. Montero over 9 years ago

Category set to Drivers - Auth
Assignee set to Jaime Melis
Target version set to Release 3.4

#2 Updated by Ruben S. Montero over 9 years ago

Target version changed from Release 3.4 to Release 3.2

#3 Updated by Jaime Melis over 9 years ago

Priority changed from High to Low

Hello Oskar, we haven't been able to reproduce your problem, in fact when applying the vlan tag command on a tapX.Y interface it fails since it doesn't exist:

Thu Jan 12 18:24:13 2012 [VMM][E]: post: Command "sudo /usr/local/bin/ovs-vsctl set Port tap77.0 tag=5" failed.
Thu Jan 12 18:24:13 2012 [VMM][E]: post: ovs-vsctl: no row "tap77.0" in table Port

What is the output for xm network-list one-<vm_id> in your case?

#4 Updated by Oskar Johansson over 9 years ago

Hi Jaime

The output from xm network-list one-48:

root@vhost1:~# xm network-list one-48
Idx BE     MAC Addr.     handle state evt-ch tx-/rx-ring-ref BE-path
0   0  02:00:0a:05:03:31    0     1      -1    -1   /-1      /local/domain/0/backend/vif/50/0

The output from ovs-vsctl show:

root@vhost1:/var/lib/one/67/images# ovs-vsctl show
ee11af98-4792-4acd-8f20-d7bf2ce3323c
    Bridge "vbr0" 
        Port "vif33.0" 
            Interface "vif33.0" 
        Port "vif54.0" 
            tag: 15
            Interface "vif54.0" 
        Port "tap54.0" 
            tag: 15
            Interface "tap54.0" 
        Port "tap53.0" 
            tag: 15
            Interface "tap53.0" 
        Port "vbr0" 
            Interface "vbr0" 
                type: internal
        Port "tap50.0" 
            tag: 15
            Interface "tap50.0" 
        Port "vbr1" 
            tag: 4
            Interface "vbr1" 
                type: internal
        Port "tap22.0" 
            tag: 15
            Interface "tap22.0" 
        Port "vif53.0" 
            tag: 15
            Interface "vif53.0" 
        Port "tap33.0" 
            Interface "tap33.0" 
        Port "vif50.0" 
            tag: 15
            Interface "vif50.0" 
        Port "tap37.0" 
            tag: 4
            Interface "tap37.0" 
        Port "vif38.0" 
            tag: 4
            Interface "vif38.0" 
        Port "vif22.0" 
            tag: 15
            Interface "vif22.0" 
        Port "tap38.0" 
            tag: 4
            Interface "tap38.0" 
        Port "vif37.0" 
            tag: 4
            Interface "vif37.0" 
        Port ln
            Interface "eth0" 
            Interface "eth1" 
    Bridge "virbr0" 
        Port "virbr0" 
            Interface "virbr0" 
                type: internal

As you can see, there's both a tapX.Y and a vifX.y. Maybe this is specific to newer versions? I found this link now:

http://zhigang.org/wiki/XenVirtualNetwork#guest-virtual-network-type

All my guests are HVM-guests right now with ioemu (Windows & FreeBSD), that would explain it.