Bug 700753 - incorrect vlan network setting didn't removed, cause the network fail to up,
Summary: incorrect vlan network setting didn't removed, cause the network fail to up,
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ovirt-node
Version: 6.1
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Joey Boggs
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-04-29 10:12 UTC by Mohua Li
Modified: 2011-12-06 19:14 UTC (History)
8 users (show)

Fixed In Version: ovirt-node-2.0.1-0.8.git51c19bc.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-06 19:14:45 UTC
Target Upstream Version:


Attachments (Terms of Use)
ifcfg* files (524 bytes, application/x-gzip)
2011-08-05 10:25 UTC, Guohua Ouyang
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1783 0 normal SHIPPED_LIVE rhev-hypervisor6 bug fix and enhancement update 2011-12-06 15:10:54 UTC

Description Mohua Li 2011-04-29 10:12:36 UTC
Description of problem:
Have server nics on the machine, and try to configure any of them with the wrong vlan id, after configure several nics, you will find there are several nics in the list display as "configured",

and also run

#ifconfig,

will get eth0, eth0.15,breth0,eth2, eth2.15,breth2,eth3, eth3.15, breth3,

then configure eth0 again, with the right vlan id,

we will eth0,eth0.15,eth0.20, breth0, eth2, eth2.15,breth2,eth3, eth3.15, breth3,

#brctl show,

bridge name                        interfaces
breth0                              eth0.15
                                    eth0.20
breth2                              eth2.15
breth3                              eth3.15,


as the bonding is wrong, so the network can't be up, it's mostly like 593543, but as the operation change quite much, so report a new bug,




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

rhevh 6.1-20110427,


How reproducible:
always

Steps to Reproduce:
1,configure several nics in the menu with wrong vlan id,
2,then configure the nic with the right vlan id again,

  
Actual results:

Expected results:
network could be up, and didn't save the incorrect result

Additional info:

after do the following operation, network could be up,

#brctl delbr breth0 eth0.15
#unpersist /etc/sysconfig/network-scripts/ifcfg-eth0.15
#rm -rf /etc/sysconfig/network-scripts/ifcfg-eth0.15
#service network restart

Comment 4 Guohua Ouyang 2011-08-05 10:25:22 UTC
Created attachment 516870 [details]
ifcfg* files

Tested on rhevh 6.2-11, steps:
1. configure 1st nic with wrong vlan id, cannot obtain ip and didn't show up.
2. configure 2nd nic with correct vlan id, obtained ip and is up.
3. configure 2rd nic with correct vlan id, obtained ip and is up.

So the original issue should be fixed, but all of them show configured in TUI.
And I have a questions is that do we support more than one nic is up with ip? then which one should be choosing by rhevm? randomly?

Comment 5 Alan Pevec 2011-08-05 10:40:35 UTC
In previous RHEV-H versions only one interface could be configured, the one used as the management interface, that should stay for the RHEV use-case.
But for the standalone use-cases in the upstream, we actually do want to be able to configure multiple interfaces.

> then which one should be choosing by rhevm? randomly?

vdsm-reg does this magic, it uses traceroute to figure out which is the outgoing interface towards specified management server and renames its bridge to "rhevm"
(that's the background of bug 725392 btw)

Comment 6 Alan Pevec 2011-08-05 10:48:21 UTC
(In reply to comment #5)
> that should stay for the RHEV use-case.

Actually, thanks to vdsm-reg magic it shouldn't hurt RHEV use-case to have multiple NICs configured, we'll just need to document only one interface is used for the management and the rest should be configured via RHEV-M.

Comment 7 Guohua Ouyang 2011-08-12 02:45:18 UTC
set status to verified since the original issue is fixed.

Comment 9 Zac Dover 2011-10-12 06:00:24 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
During the network configuration, when a network interface was configured with VLAN enabled and then reconfigured without it, the incorrect VLAN settings were not removed. With this update, the old configuration is removed as expected.

Comment 10 Alan Pevec 2011-10-25 10:43:45 UTC
Deleted Technical Notes Contents.

Old Contents:
During the network configuration, when a network interface was configured with VLAN enabled and then reconfigured without it, the incorrect VLAN settings were not removed. With this update, the old configuration is removed as expected.

Comment 11 errata-xmlrpc 2011-12-06 19:14:45 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1783.html


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