Bug 1117303 - [RFE] Don't count on vdsm to report the management interface
Summary: [RFE] Don't count on vdsm to report the management interface
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: RFEs
Version: 3.6.0
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: ovirt-3.6.0-rc
: 3.6.0
Assignee: Dan Kenigsberg
QA Contact: Meni Yakove
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-08 13:15 UTC by Dan Kenigsberg
Modified: 2016-03-09 20:48 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-03-09 20:48:48 UTC
oVirt Team: Network
Target Upstream Version:
Embargoed:
nyechiel: Triaged+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2016:0376 0 normal SHIPPED_LIVE Red Hat Enterprise Virtualization Manager 3.6.0 2016-03-10 01:20:52 UTC
oVirt gerrit 35895 0 master MERGED backend: engine resolving host's active interface Never

Description Dan Kenigsberg 2014-07-08 13:15:08 UTC
Description of problem:

During deployment of a new host, Engine needs to know which of the host's interfaces is used to connect to Engine. Currently, this is exposed by the lastClientIface element of getVdsCaps verb. However, this approach is problematic, as we plant to remove the requirement of direct Engine-Vdsm TCP connection, without which, Vdsm cannot compute this element.

Instead, it is suggested that Vdsm would expose the output of `ip get route addr`, so that Engine would be able to guess which on top of which host should it configure the management network. Note that this would only be a guess, as Vdsm may sit behind NAT with no route to Engine. In that case, automatic deployment of the management network would be skipped.

Comment 2 Lior Vernia 2014-10-29 09:56:23 UTC
Moving back to POST as Eliraz also needs to get patches merged for this to work :) Please move to MODIFIED when the entire feature is functioning.

Comment 3 Petr Horáček 2014-10-29 10:15:56 UTC
Ok, thanks for the notice :)

Comment 6 Lior Vernia 2014-12-03 15:59:06 UTC
Due to possible issues with deployments where the engine is behind NAT, we'll try to avoid using the getRoute verb. Dan suggested an interesting solution, in which we'll resolve the hostname (if needed), and look for its IP address among the reported IP addresses of the NICs in getVdsCaps; the one that fits is the "active NIC". This would be quite a small fix, exclusive to the engine side.

Comment 7 Max Kovgan 2015-06-28 14:13:39 UTC
ovirt-3.6.0-3 release

Comment 10 errata-xmlrpc 2016-03-09 20:48:48 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHEA-2016-0376.html


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