Bug 1400366 - default_route custom property
Summary: default_route custom property
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.1.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ovirt-4.1.1
: ---
Assignee: Dan Kenigsberg
QA Contact: Michael Burman
URL:
Whiteboard:
Depends On: 1200963
Blocks: 1432730
TreeView+ depends on / blocked
 
Reported: 2016-12-01 01:26 UTC by Germano Veit Michel
Modified: 2021-08-30 13:28 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
This update allows you to change the default network used by the host from the management network (ovirtmgmt) to a non-management network.
Clone Of:
Environment:
Last Closed: 2017-06-21 04:17:16 UTC
oVirt Team: Docs
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHV-43310 0 None None None 2021-08-30 13:28:55 UTC
Red Hat Knowledge Base (Solution) 2956471 0 None None None 2017-03-07 22:02:08 UTC
Red Hat Product Errata RHEA-2017:0997 0 normal SHIPPED_LIVE Red Hat Virtualization Manager (ovirt-engine) 4.1 GA 2017-04-18 20:11:26 UTC
oVirt gerrit 66127 0 None None None 2017-03-08 15:47:46 UTC

Description Germano Veit Michel 2016-12-01 01:26:40 UTC
Description of problem:

- Document the feature introduced by BZ #1200963
- The feature is currently being targeted for RHV 4.2

These are the steps:

1. In the Manager, open a console and add the custom property.
# engine-config -s CustomDeviceProperties='{type=interface;prop={default_route=^(true|false)$}}'

2. On each host:
   2.1 Set the property to False on the management (ovirtmgmt|rhevm) network
   2.2 Set the property to True on the desired new default route network
   2.3 Set a next-hop IP address (Gateway) in the new default route network

3. Apply configurations

Two important notes that must be added to the docs:
* This configuration is PER HOST, and needs to be done on each host.
* If the gataway for the new default route network is not set, it will be IGNORED. Leaving the gateway blank will NOT set device based route (such as for proxy-arp scenarios).

Comment 1 Germano Veit Michel 2016-12-01 01:28:22 UTC
Adding to the second note above, to make it clearer:
* Leaving the gateway blank for the new default route network will result in no default route set in the host main routing table.

Comment 2 Yaniv Lavi 2016-12-06 12:59:38 UTC
Which versions contain this feature?

Comment 3 Dan Kenigsberg 2016-12-13 12:46:39 UTC
https://gerrit.ovirt.org/#/q/Iaf392ea05e1e39acbf1b74a7a31acda9e750b36e

Currently, only in 4.1

Comment 4 Lucy Bopf 2017-03-06 05:11:49 UTC
Assigning to Byron for review.

Comment 5 Dan Kenigsberg 2017-03-06 08:07:42 UTC
Marina, https://access.redhat.com/solutions/1407933 should not be proposed to customers once 4.1 is released. Instead, the method described in comment 0 should be used.

What should I do to modify this KB item?

Comment 6 Marina Kalinin 2017-03-07 04:00:40 UTC
(In reply to Dan Kenigsberg from comment #5)
> Marina, https://access.redhat.com/solutions/1407933 should not be proposed
> to customers once 4.1 is released. Instead, the method described in comment
> 0 should be used.
> 
> What should I do to modify this KB item?

This is done.
Please refresh the solution.
If you really want to modify kcs solution - reach out to me separately and we can work it out.

Comment 7 Marina Kalinin 2017-03-07 04:16:19 UTC
Dan, probably I misunderstand something here in the instructions.
If I add this property under CustomDeviceProperty, I can see it only under general Networks tab, when editing vNic profile. And I see nowhere under hosts' networking setup where I can set it up, except the actual IP and Gateway setup.

Maybe the instructions meant to say:
1. Add default route as customer device property. 
2. Modify ALL the logical networks in the Data Center to specify which will be the default route and which won't. (only 1 network can have default_route=true)
3. Modify EACH host and make sure the interface that is on the logical network to be served as default route, has the GATEWAY value specified.

Comment 8 Dan Kenigsberg 2017-03-07 07:12:38 UTC
OMG, seems like a severe case of dyslexia. Thank you, Marina, for calling me out on it.

  engine-config -g UserDefinedNetworkCustomProperties
  engine-config -s UserDefinedNetworkCustomProperties='default_route=^(true|false)$'

should be used in order to expose the 'default_route' property on each network attachment. Other than that, comment 0 is correct.

Comment 9 Marina Kalinin 2017-03-07 22:02:08 UTC
I documented the suggested solution in this kcs:
https://access.redhat.com/solutions/2956471

Comment 11 Marina Kalinin 2017-03-09 18:48:40 UTC
Hi Michael,

Can you please review my kcs for this feature to see if anything is missing there? And if all good, docs team can push it directly to the guides.

https://access.redhat.com/solutions/2956471

Comment 12 Michael Burman 2017-03-12 09:33:40 UTC
(In reply to Marina from comment #11)
> Hi Michael,
> 
> Can you please review my kcs for this feature to see if anything is missing
> there? And if all good, docs team can push it directly to the guides.
> 
> https://access.redhat.com/solutions/2956471

Hello Marina, 

I reviewed your kcs for this feature and it's good, nothing missing)

Comment 13 Lucy Bopf 2017-03-14 06:51:28 UTC
Marina, to confirm, it sounds like the next step is to move this bug back to the Documentation component, and set it back to NEW so we can triage it and find an available writer. Is that correct?

Comment 14 Dan Kenigsberg 2017-03-14 07:05:45 UTC
Lucy, this bug introduces a (minor) functionality change; Maybe you can handle it as a new feature request that requires its own documentation, based on the doctext I've provided?

Comment 15 Lucy Bopf 2017-03-16 03:37:36 UTC
Thanks, Dan. I'll leave this one on ovirt-engine then, and have raised bug 1432730 to track the documentation updates.

Comment 19 Dan Kenigsberg 2017-06-21 04:17:16 UTC
Yep, no idea why Errata did not do so.


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