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"
(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?
(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
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?
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.
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.
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.
*** Bug 1075192 has been marked as a duplicate of this bug. ***
*** Bug 1064861 has been marked as a duplicate of this bug. ***
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.
(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
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".
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