Bug 858984
Summary: | [RHEV-H 6.3] NIC failed to up after configured it by using "DHCP" Protocol with vlanid and reboot rhev-h. | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | haiyang,dong <hadong> | ||||||
Component: | ovirt-node | Assignee: | Mike Burns <mburns> | ||||||
Status: | CLOSED ERRATA | QA Contact: | Virtualization Bugs <virt-bugs> | ||||||
Severity: | urgent | Docs Contact: | |||||||
Priority: | urgent | ||||||||
Version: | 6.3 | CC: | acathrow, achan, bsarathy, chchen, cpelland, cshao, fdeutsch, gouyang, hadong, hambrose, jboggs, leiwang, mburns, nhorman, ovirt-maint, tgraf, ycui | ||||||
Target Milestone: | rc | Keywords: | Regression, ZStream | ||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | ovirt-node-2.5.0-5.el6 | Doc Type: | Bug Fix | ||||||
Doc Text: |
Timing changes in the kernel exposed an issue with HWADDR errors in the configuration file. Name clashes with VLAN network interfaces containing the hardware address of its parent network interface occurred which caused udev to rename the interfaces, which in turn made the network interfaces fail to come up. This fix removes setting the HWADDR entry in the VLAN network interface config files to prevent udev from renaming the interfaces. All network interfaces should come up correctly.
|
Story Points: | --- | ||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2013-02-28 16:39:35 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: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 860335 | ||||||||
Attachments: |
|
Created attachment 614819 [details]
screenshot of An Exception has occurred
If using above Steps don't Reproduce it, maybe can use following steps: 1. Clean install rhev-hypervisor6-6.3-20120913.1.el6_3. 2. Configure network. 3. Enter network detail page and configure network by using "DHCP" with vlanid 4. After configured nic success,reboot rhev-h. 5. If after step 1-4, still can't reproduce it, you can configure another nic by using "DHCP" with vlanid, then reboot again. Just adding some debug informations: $ uname -a Linux localhost.localdomain 2.6.32-279.9.1.el6.x86_64 #1 SMP Fri Aug 31 09:04:24 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux Just a note: this is not 100% reproducible. It's 100% reproducible on a single machine, and thus far not on any other machines. This bug also exist in build rhev-hypervisor6-6.3-20120920.0.rhev31.el6_3 on QE's env. Can you please attach the output dmesg of the machine? Please also attach /var/log/messages Try to test this bug with the build that was provided by Comment 27 again and again. Can't reproduce this issue on these two quad bcm nics of hp-xw4550-02 machine. (In reply to comment #28) > Try to test this bug with the build that was provided by Comment 27 again > and again. Can't reproduce this issue on these two quad bcm nics of > hp-xw4550-02 machine. sorry for that i did not say clear number times what i try to test this bug. Try to check this bug with the build that was provided by Comment 27 for five times. Can't reproduce this issue on these two quad bcm nics of hp-xw4550-02 machine. At the same time,I noticed that the line "HWADDR=00:10:10:18:a4:a0" was missing in the /etc/syscongfig/network-scripts/ifcfg-eth0.20 of rhev-hypervisor6-6.3-20120920.0.rhev31.auto207.el6_3.iso Test version: rhev-hypervisor6-6.4-20121015.1.el6. ovirt-node-2.5.0-7.el6_4.noarch Test step: 1. Clean install rhev-hypervisor6-6.3-20120913.1.el6_3. 2. Configure network. 3. Enter network detail page and configure network by using "DHCP" with vlanid 4. After configured nic success,reboot rhev-h. Test result: NIC can up after configured it by using "DHCP" Protocol with vlanid and reboot. So the bug is fixed, change bug status to VERIFIED. Re-test with version rhev-hypervisor6-6.4-20121212.1.el6, Test step: 1. Clean install rhev-hypervisor6-6.3-20120913.1.el6_3. 2. Configure network. 3. Enter network detail page and configure network by using "DHCP" with vlanid 4. After configured nic success,reboot rhev-h. Test result: NIC can up after configured it by using "DHCP" Protocol with vlanid and reboot. So the bug was fixed. 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-2013-0556.html |
Created attachment 614815 [details] screenshot of nic failed to up Description of problem: At first, clean install rhev-hypervisor6-6.3-20120913.1.el6_3,configure network by using "DHCP" Protocol with vlanid,the network can be configured success,then reboot rhev-h, but the nic failed to up(Seen nicfailedtoup.png ),after login rhev-h, if configure that nic("DHCP" with vlanid) again,throw An Eeception(Seen AnExceptionhasoccurred.png). Version-Release number of selected component (if applicable): rhev-hypervisor6-6.3-20120913.1.el6_3 How reproducible: 100% Steps to Reproduce: 1. Clean install rhev-hypervisor6-6.3-20120913.1.el6_3. 2. Configure network. 3. Enter network detail page and configure network by using "DHCP" with vlanid 4. After configured nic success,reboot rhev-h. Actual results: NIC failed to up after configured it by using "DHCP" Protocol with vlanid and reboot. Looks like the eth1 is missing in /sys/class/net/ after the reboot: #ls /sys/class/net/*: bond0/ bond3/ lo/ eth2/ bond1/ bond4/ eth0/ eth3/ bond2/ bonding_masters eth1.20/ breth1/ Expected results: NIC can still success to up after configured it by using "DHCP" Protocol with vlanid and reboot. Additional info: 1.No this issue in the rhev-hypervisor6-6.3-20120815.0.el6_3 by using the same nic(hp-xw4550-02 machine),so it is a regression bug. 2. Cannot reproduce the bug on RHEL63 with the same kernerl version.