Bug 1269587 - Updating to vdsm-4.16.26-1.el7ev.x86_64 causes networking to be lost on RHEV Host (Linux, not RHEV-H)
Summary: Updating to vdsm-4.16.26-1.el7ev.x86_64 causes networking to be lost on RHEV...
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: 3.5.4
Hardware: x86_64
OS: Linux
high
high
Target Milestone: ---
: ---
Assignee: Dan Kenigsberg
QA Contact: Meni Yakove
URL:
Whiteboard: network
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-07 15:54 UTC by Robert McSwain
Modified: 2019-09-12 09:03 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-01-27 09:49:33 UTC
oVirt Team: Network
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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.


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