Bug 1163365

Summary:	[RFE] Require network interfaces with non-VM roles to have IP configuration (Static or DHCP boot protocols)
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	David Jaša <djasa>
Component:	RFEs	Assignee:	Scott Herold <sherold>
Status:	CLOSED ERRATA	QA Contact:	Gil Klein <gklein>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.5.0	CC:	bazulay, danken, eedri, gklein, iheim, lpeer, lsurette, mburman, mgoldboi, nyechiel, rbalakri, Rhev-m-bugs, yeylon, ykaul, ylavi
Target Milestone:	ovirt-3.6.0-rc	Keywords:	FutureFeature, Improvement
Target Release:	3.6.0	Flags:	nyechiel: Triaged+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:	With this release, role-bearing network interfaces must have IP configuration, to ensure that they can function as is expected from their role. Red Hat Enterprise Virtualization Manager will no longer allow configuring role-bearing NICs with no means to actualize the role function.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-03-09 20:51:21 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Network	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1136329
Bug Blocks:

Description David Jaša 2014-11-12 14:58:35 UTC

Description of problem:
Currently, it's perfectly possible to e.g. set up a separate display network and configure respective host interfaces with Boot Protocol: None which effectively prevents console access (or even guest start, I don't remember now). RHEV should do better: for all network roles that do require working IP configuration (which everything but VM Network role), the respective interface would require DHCP or Static Boot protocol setting.

Namely, in the UI, when the RHEV network with any IP-requiring role is assigned to an interface, RHEV should only allow to save the interface only if Boot Protocol is set to Static or DHCP. Similarly, when trying to do analogous operation in the API, API should return a suitable error.

Version-Release number of selected component (if applicable):
up to 3.5

How reproducible:
always

UI:
Steps to Reproduce:
1. create a separate display/migration/... network
2. assign the network to an interface in Setup Host Networks
3. look at the interface settings, go back to the main dialog
4. save host network

Actual results:
2. main dialog doesn't show anything special about the newly-assigned network
3. Boot Protocol is set None (because of bug 1080366)
4. host network is successfully saved

Expected results:
2. main dialog shows some warning that something is wrong with this network
3. None protocol is disabled, user has to choose Static or DHCP in order to save interface configuration
4. new network configuration can only be saved if IP is configured for the respective network

API:

I didn't try to reproduce via API so just guessing:
PUT /api/hosts/<host_id>/nics/<unassigned_nic_id> HTTP/1.1

<host_nic>

<network id="display_network_id"/>
</host_nic>

Actual result: network gets assigned
Expected result: RHEV-M refuses to assign the network with suitable error code & message

Additional info:

Comment 1 Nir Yechiel 2014-11-16 11:02:23 UTC

Hi Lior,

Need your help here to better understand this one:

1. Is there any use case for setting up a non-VM network without IP address configuration? I want to say just no, but wanted to get your input as well

2. Assuming there is no such use case and we want to force IP configuration for those kind of networks, how do you estimate the complexity/effort here? Can we scope it for 3.6?


Thanks,
Nir

Comment 2 Lior Vernia 2014-11-16 11:43:56 UTC

I can't think of any use case for having NONE boot protocol on a non-VM network (even if it isn't display/migration), but usually Dan is able to think of something exotic?...

If no such case exists, blocking in Setup Networks should be easy. However we need to think what we want to do in two cases:

1. If a network is already setup as bridged and with NONE boot protocol, and then changed to be bridgeless. Default behavior would be Setup Networks failures on all hosts where there's NONE boot protocol. This sounds okay to me.

2. Similar issue if a network (either bridged or bridgeless) doesn't have any roles assigned to it and is configured with NONE boot protocol, and is then assigned the role... I wouldn't want to fail this, because some hosts might have an IP address for this network, and I also wouldn't want to move hosts to non-operational state (see Bug 1135779 for relevant discussion concerning display network). But if we don't do anything, then we'll get to a state where the host is in "inconsistent" state - networks with roles don't have boot protocols but seemingly all is working, but subsequent Setup Networks command will fail because of this.

These are just preliminary thoughts - the point is this isn't trivial. I also want the input from Dan first.

Comment 3 Dan Kenigsberg 2014-11-17 16:15:54 UTC

The only reason I see for a network with no IP address is if it is used as layer-2 network for VMs.

I support implementing this RFE. If someone happens to want something more exotic, they can implement it as a before_network_setup vdsm hook.

Comment 5 Michael Burman 2015-10-07 05:35:57 UTC

Verified on - rhevm-3.6.0-0.18.el6.noarch

- When trying to set a network that is already attached to host(bootproto=none) with one of the Roles (migration/display/gluster), we will get the next error message -->

Operation Canceled:

Error while executing action: Cannot edit Network. IP address has to be set for the NIC that bears a role network. Network: named1, Nic: enp6s0 on host orchid-vds2.qa.lab.tlv.redhat.com violates that rule.


- When setting a network(not attached to host yet) with one of the Roles (migration/display/gluster), then attaching to host via Setup Networks, but not setting bootproto(dhcp/static ip) and trying to approve operation, we will get the next error message-->

Operation Canceled:

Error while executing action: 

silver-vdsb.qa.lab.tlv.redhat.com:
Cannot setup Networks. Role (migration/display/gluster) network 'vm_5000' hasn't boot protocol assigned.

Comment 9 errata-xmlrpc 2016-03-09 20:51:21 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