Bug 1183751

Summary: RHEVH 7.0 latest do not contain latest dhcp package
Product: Red Hat Enterprise Virtualization Manager Reporter: Ilanit Stein <istein>
Component: rhev-hypervisorAssignee: Fabian Deutsch <fdeutsch>
Status: CLOSED DUPLICATE QA Contact: Virtualization Bugs <virt-bugs>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 3.5.0CC: cshao, danken, ecohen, fdeutsch, gklein, iheim, jpopelka, lsurette, mavital, pstehlik, sherold, ycui, yeylon, ylavi
Target Milestone: ---Keywords: Reopened, TestOnly, Triaged
Target Release: 3.5.0-1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: node
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-10 19:45:57 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Node RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1164311    
Attachments:
Description Flags
journalctl output for comment 13
none
varlog for comment 13
none
/etc/sysconfig/* for comment 13 none

Description Ilanit Stein 2015-01-19 16:48:52 UTC
Description of problem:
RHEV-H 7.0, rhev-hypervisor7-7.0-20150114.0.el7ev contain dhcp-common-4.2.5-27.el7_0.1.x86_64, instead of latest dhcp version,dhcp-4.2.5-35.el7,
which fixes Bug 1116004 - "dhclient refuses to renew address if there's other interface on the same subnet" , a bug that may cause loss of connection to rhev-h.


Version-Release number of selected component (if applicable):
rhev-hypervisor7-7.0-20150114.0.el7ev

Comment 1 Fabian Deutsch 2015-01-19 17:03:52 UTC
dhcp-4.2.5-35.el7 is only available for RHEL 7.1.

If we need that bug fixed in 7.0 the we need to request a z.stream for bug 1116004.

Ilanit, do we need a z-stream - how severe is that bug?

Comment 2 Dan Kenigsberg 2015-01-19 17:38:02 UTC
The dhclient bug has been fixed in 7.0.z by bug 1148345, and dhcp-4.2.5-27.el7_0.2 has been released on 2014-10-06.

Any idea why it was not included in rhe-h generated on 2015-01-14? Could it be that we are missing other 7.0.z fixes?

Comment 4 Dan Kenigsberg 2015-01-19 21:29:50 UTC
So let us keep this bug open, to make sure the correct package is included in the next build.

Comment 6 Fabian Deutsch 2015-01-29 15:48:05 UTC
This bug does currently not help, because the dhcp build which should fix it, doesn't seem to fix it completely.

Comment 10 Ying Cui 2015-01-30 03:37:23 UTC
checked comment 7 env.
[root@puma22 ~]# cat /etc/system-release
Red Hat Enterprise Virtualization Hypervisor 7.0 (20150123.0.el7ev)
[root@puma22 ~]# rpm -q dhclient dhcp-common
dhclient-4.2.5-27.el7_0.2.x86_64
dhcp-common-4.2.5-27.el7_0.2.x86_64

The latest rhel 7.0.z dhcp packages(dhcp-4.2.5-27.el7_0.2) are already in RHEVH.

Comment 11 Ying Cui 2015-01-30 03:45:40 UTC
let me move qa_ack+ firstly, because Virt QE need to reproduce this bug firstly then give ack. 
See comment 7 and comment 10, this issue does not seem to be a simple build correct dhcp pkg because we already built in the correct dhcp pkgs.

Now installed 3 rhevh 7.0 in Virt QE lab, then I will check whether these rhevh 7.0 network can pass the first night. will give update later.

Comment 12 Jiri Popelka 2015-01-30 15:49:00 UTC
All I can say at the moment is that bug #1187244, bug #1186727 and bug #1116004 are all different issues.

Comment 13 Ying Cui 2015-01-31 05:54:09 UTC
All 3 RHEVH host I setup them on comment 10 about 24+ hours ago.
The Host network with DHCP is losing connectivity.

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp63s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master rhevm state UP qlen 1000
    link/ether 00:24:21:7f:b7:19 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::224:21ff:fe7f:b719/64 scope link 
       valid_lft forever preferred_lft forever
4: rhevm: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:24:21:7f:b7:19 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::224:21ff:fe7f:b719/64 scope link 
       valid_lft forever preferred_lft forever
5: ;vdsmdummy;: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN 
    link/ether b2:29:80:0a:49:ab brd ff:ff:ff:ff:ff:ff

# ifconfig
enp63s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::224:21ff:fe7f:b719  prefixlen 64  scopeid 0x20<link>
        ether 00:24:21:7f:b7:19  txqueuelen 1000  (Ethernet)
        RX packets 590010  bytes 74249621 (70.8 MiB)
        RX errors 0  dropped 3081  overruns 0  frame 0
        TX packets 27427  bytes 13976834 (13.3 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 18  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 720  bytes 99962 (97.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 720  bytes 99962 (97.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

rhevm: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::224:21ff:fe7f:b719  prefixlen 64  scopeid 0x20<link>
        ether 00:24:21:7f:b7:19  txqueuelen 0  (Ethernet)
        RX packets 576984  bytes 62050455 (59.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 27285  bytes 13844564 (13.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

#brctl show
bridge name	bridge id		STP enabled	interfaces
;vdsmdummy;		8000.000000000000	no		
rhevm		8000.0024217fb719	no		enp63s0

# ethtool enp63s0|grep Link
	Link detected: yes

# rpm -q initscripts kernel ovirt-node dhclient dhcp-common
initscripts-9.49.17-1.el7_0.1.x86_64
kernel-3.10.0-123.13.2.el7.x86_64
ovirt-node-3.2.1-6.el7.noarch
dhclient-4.2.5-27.el7_0.2.x86_64
dhcp-common-4.2.5-27.el7_0.2.x86_64

Comment 14 Ying Cui 2015-01-31 05:56:13 UTC
Created attachment 986382 [details]
journalctl output for comment 13

Comment 15 Ying Cui 2015-01-31 05:56:47 UTC
Created attachment 986383 [details]
varlog for comment 13

Comment 16 Ying Cui 2015-01-31 05:57:31 UTC
Created attachment 986384 [details]
/etc/sysconfig/* for comment 13

Comment 17 Ying Cui 2015-01-31 06:01:33 UTC
BTW, after renew the IP address by # dhclient enp63s0
Then the ip address will be renewed.

Comment 18 Ying Cui 2015-01-31 06:12:24 UTC
Now to re-check the whole bug, suggest to split the comment 7 and comment 13 issue to new bug to trace detail losing connection issue. And need to reconsider the bug component.
Because current rhevh 7.0 build(20150123.0.el7ev) already had contained the correct dhclient-4.2.5-27.el7_0.2.x86_64 and dhcp-common-4.2.5-27.el7_0.2.x86_64 matched bug description and bug summary. Thanks.

Comment 21 Ying Cui 2015-02-04 16:33:29 UTC
Virt QE side, this is GA blocker. See comment 12, and comment 20. which bug is trace this issue fix?

Comment 22 Gil Klein 2015-02-05 15:27:56 UTC
The main issue in this BZ is upgrading dhclient to dhcp-common-4.2.5-27.el7_0.1.x86_64, which is less critical then the problem described in comment #7 and comment #13.

I've created a new BZ #1189837, in order to track the connectivity lose (even when only one interface is connected).

Comment 23 Ying Cui 2015-02-10 09:38:02 UTC
this bug is flag 3.5.0, please ensure need it into 3.5.0 or 3.5.0-1? Thanks

Comment 24 Fabian Deutsch 2015-02-10 19:45:57 UTC
Closing this build as a dupe, because:

At the time of build 
dhcp-common-4.2.5-27.el7_0.1.x86_64

was the latest one, dhcp-4.2.5-35.el7 is intended for RHEL 7.1

Today the latest build is:

$ brew latest-pkg rhevm-3.5-rhel-7.0-rhevh-build dhcp
Build                                     Tag                   Built by
----------------------------------------  --------------------  ----------------
dhcp-4.2.5-27.el7_0.2                     rhel-7.0-z            jpopelka


But anyhow, I'm closing this, because the issue described in comment 7 is tracked in bug 1189837, and we've also got other bugs covering the different problems with dhcp.

*** This bug has been marked as a duplicate of bug 1189837 ***