Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1065256 - RHEVH rename NIC name from "eth0" into "em1" after upgrade rhevh on hp smbios 2.6+ machine
Summary: RHEVH rename NIC name from "eth0" into "em1" after upgrade rhevh on hp smbios...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-node
Version: unspecified
Hardware: Unspecified
OS: Unspecified
urgent
high
Target Milestone: ---
: 3.5.0
Assignee: Ryan Barry
QA Contact: Virtualization Bugs
URL:
Whiteboard: node
: 1064861 1075192 (view as bug list)
Depends On:
Blocks: 1065425 1073044 1123329 rhev3.5beta 1156165
TreeView+ depends on / blocked
 
Reported: 2014-02-14 08:13 UTC by haiyang,dong
Modified: 2018-12-06 15:53 UTC (History)
20 users (show)

Fixed In Version: ovirt-node-3.0.1-18.el6.7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-11 20:52:41 UTC
oVirt Team: Node


Attachments (Terms of Use)
attached Screenshot (deleted)
2014-02-14 08:13 UTC, haiyang,dong
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2015:0160 normal SHIPPED_LIVE ovirt-node bug fix and enhancement update 2015-02-12 01:34:52 UTC
Red Hat Bugzilla 1034164 None None None Never

Internal Links: 1034164

Description haiyang,dong 2014-02-14 08:13:41 UTC
Created attachment 863155 [details]
attached Screenshot

Description of problem:
Clean auto install rhevh-6.5-20140120.0 into hp smbios 2.6+ machine by using follow parameters:
BOOTIF=MACADDRESS storage_init=/dev/sda firstboot
Then login this version and check that network of nic "eth0" was up.
Then upgrade it into "rhevh-6.5-20140212.0" via tui.After upgrade success, login the new version
and check that RHEVH rename NIC name from "eth0" into "em1" and network of nic "em1" was up:
[root@dhcp-10-94 admin]# ifconfig 
em1       Link encap:Ethernet  HWaddr 24:BE:05:14:95:A1  
          inet addr:10.66.10.94  Bcast:10.66.11.255  Mask:255.255.252.0
          inet6 addr: fe80::26be:5ff:fe14:95a1/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1563 errors:0 dropped:0 overruns:0 frame:0
          TX packets:110 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:120285 (117.4 KiB)  TX bytes:24823 (24.2 KiB)
          Interrupt:20 Memory:f7f00000-f7f20000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

but the item of Networking still shown "Networking: Unknown eth0" in status page.(seen Status-jpage.png)


Version-Release number of selected component (if applicable):
rhevh-6.5-20140212.0.iso
ovirt-node-3.0.1-18.el6_5.6

How reproducible:
100%


Steps to Reproduce:

Actual results:

Expected results:

Additional info:
Clean auto install rhevh-6.5-20140120.0 into hp smbios 2.6+ machine by using follow parameters:
BOOTIF=MACADDRESS storage_init=/dev/sda firstboot,then upgrade it into itself via tui, no this issue, so it's a regression bug when upgrade from "rhevh-6.5-20140120.0" into "rhevh-6.5-20140212.0.iso"

Comment 7 Fabian Deutsch 2014-02-21 09:54:31 UTC
(In reply to haiyang,dong from comment #0)
> Additional info:
> Clean auto install rhevh-6.5-20140120.0 into hp smbios 2.6+ machine by using
> follow parameters:
> BOOTIF=MACADDRESS storage_init=/dev/sda firstboot,then upgrade it into
> itself via tui, no this issue, so it's a regression bug when upgrade from
> "rhevh-6.5-20140120.0" into "rhevh-6.5-20140212.0.iso"

Dong,

when you only install 6.5, what is the name of the NIC in that case?

Comment 8 haiyang,dong 2014-02-21 10:43:44 UTC
(In reply to Fabian Deutsch from comment #7)
> (In reply to haiyang,dong from comment #0)
> > Additional info:
> > Clean auto install rhevh-6.5-20140120.0 into hp smbios 2.6+ machine by using
> > follow parameters:
> > BOOTIF=MACADDRESS storage_init=/dev/sda firstboot,then upgrade it into
> > itself via tui, no this issue, so it's a regression bug when upgrade from
> > "rhevh-6.5-20140120.0" into "rhevh-6.5-20140212.0.iso"
> 
> Dong,
> 
> when you only install 6.5, what is the name of the NIC in that case?

1. clean install  rhevh-6.5-20140212.0 on hp smbios 2.6+ machine, nic named "eth0"

2.clean install  rhevh-6.5-20140120.0 on hp smbios 2.6+ machine, nic named "eth0"

3. It will rename NIC name from "eth0" into "em1" after upgrade rhevh from "rhevh-6.5-20140120.0" into "rhevh-6.5-20140212.0" on hp smbios 2.6+ machine

Comment 9 Fabian Deutsch 2014-02-21 11:26:35 UTC
Thanks Dong.

Taking into account that bug 1063960 has been fixed for 0212 it seems as if this is a problem of the convert_to_biosdevname function.

IIUIC the convert_to_biosdevanme was needed to migrate the NIC names when biosdevname got introduced (see bug 822848). Basically to support migrations from 6.3 to 6.4.

On 6.5 we have a situation as we don't need to migrate the nics anymore. SO IMO we can drop the convert_to_biosdevname fucntion.

Joey, can you give some input here?

Comment 11 Ryan Barry 2014-02-21 15:52:10 UTC
Can we check whether or not /etc/default/ovirt/BIOSDEVNAMES_CONVERSION is set after the upgrade? It looks like that should be present if convert_to_biosdevname ran.

Comment 12 Fabian Deutsch 2014-02-21 15:55:48 UTC
Ryan, you are correct, that key should be set. My current working hypothesis is that the key is unset during the upgrade.

But as mentioned earlier, I'd rather like to remove the whole functionality as this function can do more harm than ... help.

Comment 13 Fabian Deutsch 2014-02-21 15:57:05 UTC
We've ot the following scenarios:

6.3 -> 6.5 - not allowed
6.4 -> 6.5 - conversion already happened NAME is set in ifcfg
6.5 -> 6.5 - biosdevname is used all the way

6.5 - biosdevname is used all the way


So I don't see a path where the biosdevname function is needed.

Comment 20 Fabian Deutsch 2014-03-14 11:46:05 UTC
*** Bug 1075192 has been marked as a duplicate of this bug. ***

Comment 21 Fabian Deutsch 2014-03-21 11:29:18 UTC
*** Bug 1064861 has been marked as a duplicate of this bug. ***

Comment 22 Pratik Pravin Bandarkar 2014-04-02 13:56:20 UTC
Hi,

As of now as a workaround we need to manually modify the ifcfg-x config file from host.

Customer is having 100 host in his env. So, manually modifying each host is not feasible for customer. He wants to know when the fix will get release. From internal flags it seems to be fix will get included in rhel6.6.

Is it possible to include fix in z stream? I mean any minor release of 6.5

Following is mail from SRM:

<snip>
It is really urgent for  the cust to fix the problem and they asked if the relevant definitive bz will take long time to deliver? If it is just "a few days", they would prefer to wait for definitive fix as the applying the workaround will take some time as it applies to about 100 hypervisors. Then the work would need to be repeated for applying the fix.
</snip>

Regards,
Pratik.

Comment 23 Ying Cui 2014-04-03 02:41:39 UTC
(In reply to Pratik Pravin Bandarkar from comment #22)
> Hi,
> 
> As of now as a workaround we need to manually modify the ifcfg-x config file
> from host.
> 
> Customer is having 100 host in his env. So, manually modifying each host is
> not feasible for customer. He wants to know when the fix will get release.
> From internal flags it seems to be fix will get included in rhel6.6.
> 
> Is it possible to include fix in z stream? I mean any minor release of 6.5
> 
> Following is mail from SRM:
> 
> <snip>
> It is really urgent for  the cust to fix the problem and they asked if the
> relevant definitive bz will take long time to deliver? If it is just "a few
> days", they would prefer to wait for definitive fix as the applying the
> workaround will take some time as it applies to about 100 hypervisors. Then
> the work would need to be repeated for applying the fix.
> </snip>
> 
> Regards,
> Pratik.

Hi Pratik,
  This bug has been cloned to 6.5.z yet, see bug 1073044, the patch is included into ovirt-node-3.0.1-18.el6_5.8 in RHEVH 6.5 update 3 shipped in Apr 01st,2014.
  You can download the rhev-hypervisor6-6.5-20140324.0.el6ev.noarch.rpm build.



Thanks
Ying

Comment 27 haiyang,dong 2014-11-14 12:07:18 UTC
Test version:
rhev-hypervisor6-6.6-20141107.0.iso
ovirt-node-3.1.0-0.25.20141107gitf6dc7b9.el6.noarch

Test steps:
1. Clean auto install rhevh-6.5-20140120.0 into hp smbios 2.6+ machine by using follow parameters:
BOOTIF=MACADDRESS storage_init=/dev/sda firstboot
2. Then login this version and check that network of nic "eth0" was up.
3. Then upgrade it into "rhev-hypervisor6-6.6-20141107.0.iso" via tui. After upgrade success, login the new version and check that RHEVH still nanmed nic as "eth0".Also the item of Networking also shown "Networking: Connected eth0" in status page.

so this bug has been fixed in in rhevh 6.6 for RHEV 3.5 bulid version after drop the convert_to_biosdevname fucntion.so change the status into "VERIFIED".

Comment 29 errata-xmlrpc 2015-02-11 20:52:41 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.

https://rhn.redhat.com/errata/RHEA-2015-0160.html


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