Bug 783056

Summary: 3.1 - Add logical network to rhevh cause rhevh lost connection to rhevm
Product: Red Hat Enterprise Linux 6 Reporter: Guohua Ouyang <gouyang>
Component: vdsmAssignee: Igor Lvovsky <ilvovsky>
Status: CLOSED NOTABUG QA Contact: yeylon <yeylon>
Severity: high Docs Contact:
Priority: high    
Version: 6.3CC: abaron, acathrow, bazulay, bsarathy, cshao, danken, gouyang, iheim, jboggs, leiwang, lpeer, mburns, moli, ovirt-maint, srevivo, ycui, ykaul
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: network
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-07-26 12:17:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
vdsm.log getVdsCaps output and ifconfig none

Description Guohua Ouyang 2012-01-19 08:20:15 UTC
Description of problem:
After add a logical network to rhevh host in rhevm, if it's in the same network with rhevm, the default route interface will change to the logical network device, which will cause rhevh lost its connection to rhevm.

[root@localhost admin]# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
10.66.8.0       *               255.255.252.0   U     0      0        0 rhevm
10.66.8.0       *               255.255.252.0   U     0      0        0 tt
link-local      *               255.255.0.0     U     1016   0        0 rhevm
link-local      *               255.255.0.0     U     1017   0        0 tt
default         10.66.11.254    0.0.0.0         UG    0      0        0 tt


Version-Release number of selected component (if applicable):
6.2-20120117.0

How reproducible:
100%.

Steps to Reproduce:
1. Register rhevh to rhevm and approve it in rhevm.
2. Add a logical network, which name is "tt".
3. In the host's network interface panel, select the nic which isn't used by rhevm.
4. add/edit network for it, use the logical network "tt".
5. after the logical network is up, wait for few minutes.

Actual results:
Rhevh status change to "connect" and become "Non response" finally.

Expected results:
RHEVH should keep connection to rhevm after add logical network. 

Additional info:
If the the added logical network device are not in the same network with rhevm, have no issue.

Comment 2 Mike Burns 2012-02-21 19:26:47 UTC
Once RHEV-H is registered to RHEV-M, all network config is owned by RHEV-M.  This needs to be looked at by the vdsm and/or RHEV-M teams to see how/if it can be fixed

Comment 3 Guohua Ouyang 2012-04-19 02:21:52 UTC
it also happened on RHEL63 host, tested with vdsm-4.9.6-7 & rhevm si2.1:

steps:
1. the RHEL63 host have three nics, all nics are in the same network and can obtain IP in the same network segment.
2. add the host to rhevm, the default management network "rhevm" is on eth0.
3. create a logical network with other nics (bonding with eth1 eth2).
4. when the logical network is up.
5. rhevm lost connection with RHEL63 host due to the the default route changed from "rhevm" network to the logical network device.

This let me guess whether can the logical network be in the same network segment with rhevm?

Comment 4 RHEL Program Management 2012-05-04 04:06:54 UTC
Since RHEL 6.3 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 5 Dan Kenigsberg 2012-05-08 19:59:20 UTC
could you supply the output of getVdsCaps and ifconfig from the host console (after networking is lost)? What happens if you `service network restart`? Would you provide vdsm.log with the relevant addNetwork calls?

Having two network with the same subnet is bound to end up in tears. Since this does not seem to be a regression from 6.2, we would have to tackle it in some other time.

Comment 6 Guohua Ouyang 2012-05-15 08:10:50 UTC
Created attachment 584581 [details]
vdsm.log getVdsCaps output and ifconfig

(In reply to comment #5)
> could you supply the output of getVdsCaps and ifconfig from the host console
> (after networking is lost)? What happens if you `service network restart`?
> Would you provide vdsm.log with the relevant addNetwork calls?
> 
attached the vdsm.log, getVdsCaps outout and ifconfig.

> Having two network with the same subnet is bound to end up in tears. Since this
> does not seem to be a regression from 6.2, we would have to tackle it in some
> other time.

Comment 8 Dan Kenigsberg 2012-07-26 12:17:33 UTC
Sorry for the long delay in my response, but ifconfig output was not actually attached.

I am wondering whether eth1 which was attached to the tt network was actually up and running, and accepting communication from the selected subnet.

If not, the outcome is quite expectable, and this is not a bug.

Please re-open if you can reproduce this with a recent vdsm build (> 4..9.6-23)
having tt with a different subnet than rhevm's, and a working nic.