Bug 1269587

Summary: Updating to vdsm-4.16.26-1.el7ev.x86_64 causes networking to be lost on RHEV Host (Linux, not RHEV-H)
Product: Red Hat Enterprise Virtualization Manager Reporter: Robert McSwain <rmcswain>
Component: vdsmAssignee: Dan Kenigsberg <danken>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Meni Yakove <myakove>
Severity: high Docs Contact:
Priority: high    
Version: 3.5.4CC: bazulay, danken, ecohen, lsurette, mburman, rhodain, rmcswain, ycui, yeylon, ylavi
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: network
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-01-27 09:49:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Network RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Robert McSwain 2015-10-07 15:54:59 UTC
Description of problem:
Updating to vdsm-4.16.26-1.el7ev.x86_64 and  causes networking to be lost on RHEV Host running RHEL 7.1 after a reboot

Version-Release number of selected component (if applicable):
vdsm-4.16.26-1.el7ev.x86_64 and kernel-3.10.0-229.14.1.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Update to  vdsm-4.16.26-1.el7ev.x86_64 and kernel-3.10.0-229.14.1.el7.x86_64, then reboot.

Actual results:
Networking is erased and the host is non-functional

Expected results:
Networking is not erased

Additional info:
sosreports to be provided shortly: 
-->head -n99999 */*/*/yum.log|egrep '==|vdsm-4|kernel-3'|egrep '==|Sep'
==> sosreport-prvh2.ldipbm.int.01512696-20150925165151/var/log/yum.log <==
Sep 25 09:59:33 Updated: vdsm-4.16.26-1.el7ev.x86_64
Sep 25 09:59:46 Installed: kernel-3.10.0-229.14.1.el7.x86_64
==> sosreport-prvh3.ldipbm.int.01512696-20150924114106/var/log/yum.log <==
Sep 23 08:56:42 Updated: vdsm-4.16.26-1.el7ev.x86_64
Sep 23 08:56:54 Installed: kernel-3.10.0-229.14.1.el7.x86_64

Comment 6 Robert McSwain 2015-12-08 14:10:13 UTC
Ido and Yaniv,

The customer had to manually configure the rhevm network and one of the iscsi connections because  of using a hosted engine setup.  Otherwise everything else was setup thru the manager. 

Is there anything else I can find out?

Comment 7 Dan Kenigsberg 2015-12-09 09:46:25 UTC
How did the customer configure his network and iscsi connections? via root ssh access? via gui? did he persist his config?

Comment 8 Robert McSwain 2015-12-15 19:44:42 UTC
Dan, Here's the information you were requesting:

I upgraded the hypervisors, and I did not have any network issues, the only issue I had was the cisco ucs fencing does not work anymore.  In terms of how I configured the networking, since I use a hosted-engine solution, I had to configure the rhevm interface and one iscsi interface by editing the ifcfg files, so I can setup the manager.  The only thing unusual about my config, is I had to tag the rhevm interface, I am using a cisco ucs blade, and when I used rhel 7 hypervisors I had issues with the manager, because for some reason it kept tagging the interface as vlan 0 and the manager would not communicate, so the work around that I found was to go ahead and tag the interfaces.  So once the manager was up and running all the other interfaces were configured thru the manager gui.

Comment 9 Ido Barkan 2015-12-16 11:19:03 UTC
(In reply to Robert McSwain from comment #8)
> Dan, Here's the information you were requesting:
> 
> I upgraded the hypervisors, and I did not have any network issues, the only
> issue I had was the cisco ucs fencing does not work anymore.  In terms of
> how I configured the networking, since I use a hosted-engine solution, I had
> to configure the rhevm interface and one iscsi interface by editing the
> ifcfg files, so I can setup the manager.

It is recommended to use the engine to configure the networks directly so that they will be 'owned' by vdsm and be also persisted across reboots (or can be restored if something bad has happened)

> The only thing unusual about my
> config, is I had to tag the rhevm interface, I am using a cisco ucs blade,
> and when I used rhel 7 hypervisors I had issues with the manager, because
> for some reason it kept tagging the interface as vlan 0 and the manager
> would not communicate, so the work around that I found was to go ahead and
> tag the interfaces.

This is a known issue although we are still looking for the documentation for this by Cisco. see https://bugzilla.redhat.com/show_bug.cgi?id=1279161

> So once the manager was up and running all the other
> interfaces were configured thru the manager gui.

So what is the status now? Are there still problems?

Comment 10 Yaniv Lavi 2016-01-27 09:49:33 UTC
Please reopen if you can provide the needed info.