Bug 1128412 - Can't set bonding network with vlan tag to create bridge through "Networks" Setup, but can add through "Setup Host networks"
Summary: Can't set bonding network with vlan tag to create bridge through "Networks" S...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-webadmin
Version: 3.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 3.5.0
Assignee: bugs@ovirt.org
QA Contact: Pavel Stehlik
URL:
Whiteboard: network
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-10 09:25 UTC by Andy Huang
Modified: 2023-09-14 02:45 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-08-17 10:55:23 UTC
oVirt Team: Network
Embargoed:


Attachments (Terms of Use)

Description Andy Huang 2014-08-10 09:25:41 UTC
Description of problem:

My network use vlan, and use bonding, so I need set vm use bond0.140.

when I add network "virtbr140" to "Networks" (I choose "Enable VLAN tag") through navigate tree. But when I add host, oVirt WEB always complain "the following networks are missing on host:'virtbr140'".

Now I try setup virtual bridge by manual, I add follow config to target host:

/etc/sysconfig/network-scripts/ifcfg-bond0.140:

DEVICE=bond0.140
ONBOOT=no
VLAN=yes
BRIDGE=virtbr140
MTU=1500
NM_CONTROLLED=no
HOTPLUG=no

/etc/sysconfig/network-scripts/ifcfg-virtbr140:

DEVICE=virtbr140
ONBOOT=no
TYPE=Bridge
DELAY=0
STP=off
MTU=1500
DEFROUTE=no
NM_CONTROLLED=no
HOTPLUG=no

Then I use "/etc/init.d/network restart", now I get virtbr140 as follow:

#brctl show
bridge name     bridge id               STP enabled     interfaces
virtbr140               8000.a0d3c103d194       no              bond0.140

I now set host to "Maintiance" then "reinstall", but oVirt complain "missing virtbr140" again.

I am not sure why the "ovirtmgmt" can direct use "bond0.500" (I set "ovirtmgmt" "Enable VLAN tag" use vlan 500, and not use as vm network), but when I create "virtbr140" manually but oVirt can not use it.

At last, I find I can first choose Host through navigate tree, then "Network Interfaces", in "Network Interfaces" pannel, I can use "Setup Host networks" and drag/drop "virtbr140" icon from "Unassigned Logical Networks" area to "Assigned Logical Networks" area, then saved. Now I try reinstall host, it sucessed.

Version-Release number of selected component (if applicable):

ovirt-node-3.1.0-0.0.master.20140730.git59b1407.el6.noarch
ovirt-host-deploy-1.3.0-0.0.master.20140804175631.git89155f8.el6.noarch
ovirt-hosted-engine-ha-1.2.1-0.2.master.20140805072346.el6.noarch
ovirt-node-selinux-3.1.0-0.0.master.20140730.git59b1407.el6.noarch
ovirt-hosted-engine-setup-1.2.0-0.1.master.el6.noarch
ovirt-release35-001-0.4.rc1.noarch
ovirt-node-branding-ovirt-3.1.0-0.0.master.20140730.git59b1407.el6.noarch
ovirt-engine-sdk-python-3.5.0.4-1.20140728.gitec31051.el6.noarch

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Lior Vernia 2014-08-12 14:26:58 UTC
I don't understand what the problem is. You configure a network with VLAN 140, and when you configure it on the host via the "Setup Host Networks" dialog everything works fine?

You don't need to (and generally shouldn't) configure networking on hosts by yourself - oVirt does this for you, via this "Setup Host Networks" dialog.

The web console originally complained about that network not being configured because it is marked as a required network - required networks must appear on all hosts of a cluster, otherwise a host moves to non-operational state and cannot be used to run VMs.

I THINK what didn't work in your manual configuration was that the virtbr140 device wasn't created as a VLAN device. But again, this manual configuration is not something that you would normally want to do with oVirt.

Can this bug be closed?

Comment 2 Lior Vernia 2014-08-17 10:55:23 UTC
No response and I don't see how this is a bug.

Comment 3 Red Hat Bugzilla 2023-09-14 02:45:31 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days


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