Bug 1269587 - Updating to vdsm-4.16.26-1.el7ev.x86_64 causes networking to be lost on RHEV Host (Linux, not RHEV-H)
Updating to vdsm-4.16.26-1.el7ev.x86_64 causes networking to be lost on RHEV...
Status: CLOSED INSUFFICIENT_DATA
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm (Show other bugs)
3.5.4
x86_64 Linux
high Severity high
: ---
: ---
Assigned To: Dan Kenigsberg
Meni Yakove
network
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-07 11:54 EDT by Robert McSwain
Modified: 2016-02-15 06:05 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-27 04:49:33 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Robert McSwain 2015-10-07 11:54:59 EDT
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 09:10:13 EST
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 04:46:25 EST
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 14:44:42 EST
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 06:19:03 EST
(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 04:49:33 EST
Please reopen if you can provide the needed info.

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